For the record we can't prioritize it at the moment

On 15 January 2016 at 10:06, Thomas Darimont <thomas.darimont@googlemail.com> wrote:

Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324

Cheers,

Thomas

2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger@redhat.com>:

Sounds good to me. The AdminEventBuilder.resourcePath could set it so we don't have to have the logic spread around.

On 15 January 2016 at 09:45, Thomas Darimont <thomas.darimont@googlemail.com> wrote:

Hi,

currently it is hard to figure out what actually happend when processing events, since there

is no explicit information about the actual underlying resource in an event. Currently one has to 

parse the resourcePath of an AdminEvent to deduce the involved resource.

E.g. Creating a user yields:

AdminEvent#getOperationType(): CREATE

AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472

Assigning a client role to a user yields:

AdminEvent#getOperationType(): CREATE

AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e

Removing a client role from a user yields:

AdminEvent#getOperationType(): DELETE

AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e

It would be helpful if one had more information about the actual use case.

How about introducing an AdminEvent#getResourceType() method that returns an enum value for the 

resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP, ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.

This would make it easier detect what actually happend without having to parse the resourcePath.

What do you think?

Cheers,

Thomas

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev