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 "angela (JIRA)" <ji...@apache.org> on 2016/02/12 09:03:18 UTC
[jira] [Updated] (OAK-4003) Add support for Group-Membership
actions
[ https://issues.apache.org/jira/browse/OAK-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela updated OAK-4003:
------------------------
Description:
[~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, Iterable<String> failedIds, 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, Iterable<String> failedIds, Root root, NamePathMapper namePathMapper) throws RepositoryException;
{code}
was:
[~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}
> 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, Iterable<String> failedIds, 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, Iterable<String> failedIds, Root root, NamePathMapper namePathMapper) throws RepositoryException;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)