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. > > >
