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 <[email protected]> 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 <[email protected]> > Sent: Wednesday, October 31, 2018 9:53 AM > To: [email protected] > 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 <[email protected] > > > 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 <[email protected]> > > Sent: Tuesday, October 30, 2018 7:05 PM > > To: [email protected] > > 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. >
