You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Alexander Klimetschek (JIRA)" <ji...@apache.org> on 2016/02/11 23:23:18 UTC

[jira] [Comment Edited] (OAK-4003) Add support for Group-Membership actions

    [ https://issues.apache.org/jira/browse/OAK-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143607#comment-15143607 ] 

Alexander Klimetschek edited comment on OAK-4003 at 2/11/16 10:23 PM:
----------------------------------------------------------------------

Why? What does the action have to do differently in the two variants? Should the callback get the member Ids in case the authorizable are not resolvable (anymore)? I assume it could not do anything useful with it anymore.

Resolving the Authorizable from the member ID is not necessarily trivial for the GroupAction implementation. IMO we should design this extension point based on the use cases of the extension implementations, not based on current implementation details of the security implementation.

Question is also what happens in this case:
{code}
group1.addMember(one)
group2.addMember(two)
session.save();
{code}

Will the GroupAction receive two individual {{onMemberAdded(Group, Authorizable)}} calls? Would it be possible and better if these are aggregated, so it would get a {{onMemberAdded(Group, Iterable<Authorizable>)}} callback?

If the resolution of member IDs is potentially is costly it should be straightforward to only do this if there is at least one listener being called.


was (Author: alexander.klimetschek):
Why? What does the action have to do differently in the two variants? Should the callback get the member Ids in case the authorizable are not resolvable (anymore)? I assume it could not do anything useful with it anymore.

Resolving the Authorizable from the member ID is not necessarily trivial for the GroupAction implementation. IMO we should design this extension point based on the use cases of the extension implementations, not based on current implementation details of the security implementation.

Question is also how often that gets called if this happens:
{code}
group1.addMember(one)
group2.addMember(two)
session.save();
{code}

Will the GroupAction receive two individual {{onMemberAdded(Group, Authorizable)}} calls? Would it be possible and better if these are aggregated, so it would get a {{onMemberAdded(Group, Iterable<Authorizable>)}} callback?

If the resolution of member IDs is potentially is costly it should be straightforward to only do this if there is at least one listener being called.

> Add support for Group-Membership actions
> ----------------------------------------
>
>                 Key: OAK-4003
>                 URL: https://issues.apache.org/jira/browse/OAK-4003
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: core
>            Reporter: angela
>            Assignee: Dominique Jäggi
>             Fix For: 1.6
>
>
> [~djaeggi], as discussed today it would be cool to provide an extension for the user/group actions that allowed to hook in additional processing/verification upon update of group membership.
> initial thoughts to be discussed and verified for feasibilty: 
> - create {{GroupAction}} interface extending {{AuthorizableAction}} (to not blow up the original interface with operations that only affect groups)
> - add 2 methods for addMember(s) and removeMember(s) each to cover both the add/removal by {{Authorizable}} and by multiple {{memberIds}}
> The actions should be called _after_ having successfully processed the modification and (in case on manipulation by ID) should only report those members that have been added/removed (see API contract of membership-update by ids).
> Methods could e.g. look something like
> {code}
>     void onMemberAdded(Group group, Authorizable member, Root root, NamePathMapper namePathMapper) throws RepositoryException;
>     
>     void onMembersAdded(Group group, Iterable<String> memberIds, Root root, NamePathMapper namePathMapper) throws RepositoryException;
>    void onMemberRemoved(Group group, Authorizable member, Root root, NamePathMapper namePathMapper) throws RepositoryException;
>     
>     void onMembersRemoved(Group group, Iterable<String> memberIds, Root root, NamePathMapper namePathMapper) throws RepositoryException;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)