[ 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)