Hi Vilius, I have successfully reproduced your issue with the "Delete Address" context menu item. It is a UI console bug caused by an incorrect logic check in the AddressesTable.tsx file. You can see the specific line, see https://github.com/apache/artemis-console/blob/1.7.0/artemis-console-extension/artemis-extension/packages/artemis-console-plugin/src/addresses/AddressesTable.tsx#L206
Can you create an ARTEMIS issue? https://issues.apache.org/jira/browse/ARTEMIS Thanks, Domenico On Mon, 23 Mar 2026 at 08:46, Vilius Šumskas via users <[email protected]> wrote: > > For me the original issue is fixed, but something is still strange with > permissions in the menu on the right of every address. Clicking “Delete > Address” with the limited role does nothing. Clicking delete on the same > address with a user from amq role works as expected. Steps to reproduce: > > > > Login to console with amq role and create “test” address. > Add a limited (mostly read access) “developer” role by changing > management.xml the following way: > > > > <default-access> > > <access method="list*" roles="developer,amq"/> > > <access method="get*" roles="developer,amq"/> > > <access method="is*" roles="developer,amq"/> > > </default-access> > > <role-access> > > <match domain="org.apache.activemq.artemis"> > > <access method="list*" roles="developer,amq"/> > > <access method="get*" roles="developer,amq"/> > > <access method="is*" roles="developer,amq"/> > > <access method="set*" roles="amq"/> > > <!-- Note count and browse are need to access the browse tab in > the console --> > > <access method="browse*" roles="developer,amq"/> > > <access method="count*" roles="developer,amq"/> > > <access method="deleteAddress" roles="developer,amq"/> > > <access method="destroyQueue" roles="developer,amq"/> > > <access method="*" roles="amq"/> > > </match> > > </role-access> > > > > Add a user to “developer” role and login with it into console. > Try to delete “test” address. > > > > > > -- > > Vilius > > > > From: Alexander Milovidov <[email protected]> > Sent: Friday, March 20, 2026 11:09 PM > To: [email protected] > Subject: Re: Possible bug with management ACLs > > > > Thank you all for your help! > > I checked in the new version 2.53.0 - object permissions are being granted or > displayed correctly. > I tried testing this in a test environment, but the web console took so long > to load (with around 3000 addresses with different ACLs) that I decided to > revert back to the old version for now. I'll test it later in environments > with fewer entries. > > > > пт, 20 мар. 2026 г. в 18:26, Clebert Suconic <[email protected]>: > > the download is already updated... I'm just sending the announcement now: > > https://artemis.apache.org/components/artemis/download/ > > On Fri, Mar 20, 2026 at 9:47 AM Vilius Šumskas via users > <[email protected]> wrote: > > > > Sure, as soon as tarball is available on the website. > > > > -- > > Vilius > > > > >-----Original Message----- > > >From: Clebert Suconic <[email protected]> > > >Sent: Friday, March 20, 2026 3:39 PM > > >To: [email protected] > > >Cc: Vilius Šumskas <[email protected]> > > >Subject: Re: Possible bug with management ACLs > > > > > >I'm about to release 2.53.0. Can you try in that version? > > > > > >On Fri, Mar 20, 2026 at 9:12 AM Vilius Šumskas via users > > ><[email protected]> wrote: > > >> > > >> Hi, > > >> > > >> > > >> > > >> I‘m not sure if this is the same bug, but indeed something has changed > > >> in recent > > >Artemis versions in regards to management.xml ACLs. We encountered this > > >issue > > >https://github.com/jolokia/jolokia-integration/issues/5 . It is filled > > >against Jolokia, > > >but now I’m wondering if these changes are in Artemis itself. > > >> > > >> > > >> > > >> -- > > >> > > >> Vilius > > >> > > >> > > >> > > >> From: Alexander Milovidov <[email protected]> > > >> Sent: Friday, March 20, 2026 2:25 PM > > >> To: [email protected] > > >> Subject: Possible bug with management ACLs > > >> > > >> > > >> > > >> Hi All! > > >> > > >> > > >> > > >> Recently I've discovered a possible bug in Artemis 2.50.0 and later. > > >> When I > > >configure management ACL for sending messages on a particular address, the > > >permissions for sending messages are granted only for the queue on this > > >address. I > > >checked if the user has permissions on the objects in the Artemis JMX tree. > > >> > > >> When I tried to reproduce this issue in an isolated environment, it had > > >> a different > > >effect: when I granted permissions on a particular address, the > > >permissions were > > >granted on this address and all other addresses and queues. > > >> > > >> > > >> > > >> Steps to reproduce on a fresh instance: > > >> > > >> - create a user "test" with role "test-role" and add test-role to > > >> hawtio roles; > > >> > > >> - create address TEST.IN with TEST.IN queue.\ > > >> > > >> - add an example management ACL to management.xml role-access section: > > >> > > >> <match domain="org.apache.activemq.artemis" key="address=TEST.IN"> > > >> > > >> <access method="send*" roles="amq,test-role"/> > > >> <access method="*" roles="amq"/> > > >> > > >> </match> > > >> > > >> > > >> > > >> Also I've mentioned that when I configure JMX exporter as javaagent > > >> (which > > >requires java option -Dcom.sun.management.jmxremote=true), all ACLs on > > >mbeans have no effect. Any operations for all users are available > > >regardless of > > >configured management ACLs. Anyway I plan to get rid of the JMX exporter. > > >> > > >> > > >> > > >> Both problems are reproduced in versions 2.50.0 - 2.52.0 and not > > >> reproduced in > > >previous versions. > > >> > > >> I'll later try to configure the same management ACLs using > > >> security-settings in > > >broker.xml. > > >> > > >> > > >> > > >> -- > > >> > > >> Regards, > > >> > > >> Alexander > > > > > > > > > > > >-- > > >Clebert Suconic > > > > -- > Clebert Suconic > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
