Cheers,
Thomas
2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>