[
https://issues.apache.org/jira/browse/OAK-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-2991:
---------------------------------------
Attachment: OAK-2991-testcase2.patch
Sure about declaredMemberOf(), but I have seen the problem for a declared
member (even if fetched via memberOf()). Maybe the Group object is different
between memberOf() and declaredMemberOf() (even when it's a declared member)?
Your test case is slightly different in that it's all the same session.
However, I changed that in the attached [^OAK-2991-testcase2.patch] (also moved
the session.save() outside the loop), but it still runs fine.
Maybe it's not a core Oak issue, but an integration issue with some CommitHook
etc. in our application layer (Adobe Granite/CQ). When I debugged the issue,
and stepped through removeMember(), I did see the rep:members property being
properly updated by the MembershipWriter (value being removed). However, after
the save() (which I did not step through since it's too big), looking at the
useradmin UI, the member was back.
> group.removeMember() on result of user.memberOf() does not work
> ---------------------------------------------------------------
>
> Key: OAK-2991
> URL: https://issues.apache.org/jira/browse/OAK-2991
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.2.2
> Reporter: Alexander Klimetschek
> Assignee: angela
> Priority: Minor
> Attachments: OAK-2991-testcase2.patch, OAK-2991_testcase.patch
>
>
> When using the group from the memberOf() iterator to remove a user from that
> group, the change is not persisted. One has to fetch the group separately
> from the UserManager.
> {code}
> final Iterator<Group> groups = user.memberOf();
> while (groups.hasNext()) {
> Group group = groups.next();
> group.removeMember(user); // does not work
> session.save();
>
> group = userManager.getGroup(group.getID());
> group.removeMember(user); // does work
> session.save();
> }
> {code}
> Note that {{removeMember()}} always returns true, indicating that the change
> worked. Debugging through the code, especially MembershipWriter, shows that
> the rep:members property is correctly updated, so probably some later
> modification restores the original value before the save is executed. (No JCR
> events are triggered for the group).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
