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(a)googlemail.com
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev