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.

Reply via email to