Hi, Could this be related to adding the "rep:AccessControllable" mixin if it doesn't exist on that specific node? (The AccessControlManagerImpl will update the mixins property in the case it is not there.)
It fits with the examples: > If I create the first version of a node *after* adding an ACE to it, then I can add or remove other ACE without having to checkout the node. in this case the mixin was already added prior to the versioning operation, so adding/removing ACEs will not touch the mixin > If I create the first version of the node *before* adding the first ACE, then I get the error (*OakVersion0001: Cannot change property jcr:mixinTypes on checked in node*) whenever i try to modify the node permissions without checking it out first. In this case touching the mixins would trigger the version validation on the mixing requiring a checkout/checkin of that node. best, alex On Fri, Nov 2, 2018 at 4:03 PM Marco Piovesana <pioves...@esteco.com> wrote: > Hi Angela, > let me try to rephrase my followup question. I have a versioned node and I > need to change the permissions a user has on that node. > If I try to modify the access control without checking-out the node I got > the error: *OakVersion0001: Cannot change property jcr:mixinTypes on > checked in node.* So, I ended up creating a new version each time I want to > modify the node ACL. > From this exchange of email I was under the impression that a > checkout/checkin is required when changing the node's ACL and I was > wondering why, since the access control is not part of the node versioned > information (and not something is restored when restoring a node to a > previous version). > > Marco. > > On Fri, Nov 2, 2018 at 3:40 PM Angela Schreiber <anch...@adobe.com.invalid > > > wrote: > > > Hi Marco > > > > Regarding your original question I found, that I was actually mistaken > :-) > > See OAK-6015 for the reason why IGNORED nodes are treated differently. > > > > Not sure thought I understand your followup question... you don't need to > > make a node versionable or version it in order to place/edit access > control > > information on it. But the fact that ac-content is marked with OPV IGNORE > > is an implementation detail. See also > > > http://jackrabbit.apache.org/oak/docs/security/permission/differences.html > > for details on how access to the version storage is evaluated. > > > > Kind regards > > Angela > > ________________________________________ > > From: Marco Piovesana <pioves...@esteco.com> > > Sent: Friday, November 2, 2018 3:23 PM > > To: oak-dev@jackrabbit.apache.org > > Subject: Re: ACL on versioned node > > > > Hi Angela, > > thanks for the clarification, I thought the access control content was > > versioned alongside the node. If you don't mind me asking I have another > > question though (that might be a little off topic): why is required to > > version a node to change its access control information if the access > > control information is not part of the version information? If I restore > a > > node to a previous version (that had different permission settings), the > > permission on the node are not restored alongside the node state, so why > do > > I have to version it in the first place? Am I missing something? > > > > Marco. > > > > On Wed, Oct 31, 2018 at 2:03 PM Angela Schreiber > <anch...@adobe.com.invalid > > > > > wrote: > > > > > Hi Marco > > > > > > As far as I remember the access control content is not versioned along > > > with the parent node it is attached to in the default implementation. > > This > > > is indeed due to the OPV flag set to IGNORE with the corresponding node > > > type definitions. However that cannot be changed and it is somewhat > > > unrelated to the issue you are seeing (i.e. the read only status of a > > > checked-in node). The OPV defines what happens to an item in the > subtree > > of > > > a versionable node upon checkin i.e. the creation of a new version and > > > which imformation also makes it in which form to the version storage > > > (IGNORE: not copied to version storage at all). It also has an impact > on > > > restore. You will find all the details in the specification. > > > > > > Kind regards > > > Angela > > > ________________________________________ > > > From: Marco Piovesana <pioves...@esteco.com> > > > Sent: Wednesday, October 31, 2018 9:53 AM > > > To: oak-dev@jackrabbit.apache.org > > > Subject: Re: ACL on versioned node > > > > > > Sure, > > > I'll add a JIRA for it with the test case. One more question, if I want > > to > > > separate the versioning of the node from the permission policy on it, > > can I > > > set the OPV to ignore for the relative rep:policy node? Or that just > > > doesn't work? > > > > > > Marco > > > > > > On Wed, Oct 31, 2018 at 8:52 AM Angela Schreiber > > <anch...@adobe.com.invalid > > > > > > > wrote: > > > > > > > Hi Marco > > > > > > > > Upon checkin of a versionable node (and it's non-versionable subtree) > > > > becomes read-only. I think the first behavior is a bug. Changing > > > > permissions of a checked-in node should not be possible. The reason > why > > > you > > > > are seeing it in the second case is due to the fact that a mixin is > > > > automatically added to the checked-in node. But also the modification > > of > > > > access control content in the subtree should trigger the exception > > (which > > > > it doesn't apparently) > > > > > > > > Here a quote from the specification: > > > > The node N and its connected non-versionable subtree become > read-only. > > > N's > > > > connected non-versionable subtree is the set of non-versionable > > > descendant > > > > nodes reachable from N through child links without encountering any > > > > versionable nodes. In other words, the read-only status flows down > from > > > the > > > > checked-in node along every child link until either a versionable > node > > is > > > > encountered or an item with no children is encountered. > > > > > > > > Since the policy node and the access controlled content stored > therein > > is > > > > not versionable the checkin status of it's versionable parent (or > > > ancestor > > > > for that matter) should be enforced. > > > > > > > > May I ask you to create a JIRA ticket for that? > > > > Thanks > > > > Angela > > > > > > > > ________________________________________ > > > > From: Marco Piovesana <pioves...@esteco.com> > > > > Sent: Tuesday, October 30, 2018 7:05 PM > > > > To: oak-dev@jackrabbit.apache.org > > > > Subject: ACL on versioned node > > > > > > > > Hi all, > > > > I'm using Oak 1.8.1 and I don't think I fully understand how > > permissions > > > > are handled in versioned nodes. > > > > > > > > If I create the first version of a node *after* adding an ACE to it, > > > then I > > > > can add or remove other ACE without having to checkout the node. > > > > > > > > If I create the first version of the node *before* adding the first > > ACE, > > > > then I get the error (*OakVersion0001: Cannot change property > > > > jcr:mixinTypes on checked in node*) whenever i try to modify the node > > > > permissions without checking it out first. > > > > > > > > what is the expected behavior? Checkout should be required or not to > > > modify > > > > the user's permission on the node? > > > > > > > > Marco. > > > > > >
