Hi Marco Yes, that's wired.... I just had a look at the VersionEditor that throws this exception: If OPV is IGNORE the exception will not be raised. And looking at the node type definition the rep:restrictions child node definition doesn't mark it to be IGNORED (even if the parent ACE node definition is).
So, this probably is a bug in the node type definition. Can you create an issue for this? the rep:restriction child node def should also have OPV IGNORED and then it should not raise the exception. Kind regards Angela ________________________________ From: Marco Piovesana <[email protected]> Sent: Tuesday, March 10, 2020 9:34 AM To: [email protected] <[email protected]> Subject: Re: add ACE containing restrictions throws exception Hi Angela, thanks for the reply. It feels a bit weird that I have to check-out a node to modify something that doesn't affect the versions, but if is mandatory then ok. Marco. On Tue, Mar 10, 2020 at 8:16 AM Angela Schreiber <[email protected]> wrote: > Hi Marco > > I vaguely remember that the verification for the read-only status of a > checked-in versionable node does not include the built-in access control > content. But I don't recall if that because the specification mandates this > or if it's a bug. > > But the error you get is expected: a checked-in node should be immutable. > So, you first need to call checkout in order to modify it. > > Kind regards > Angela > ________________________________ > From: Marco Piovesana <[email protected]> > Sent: Thursday, March 5, 2020 12:38 PM > To: [email protected] <[email protected]> > Subject: add ACE containing restrictions throws exception > > Hi all, > I'm trying to add an ACE with a custom restriction to a versioned node, but > when I save the session I get the error: > *OakVersion0001: Cannot add property jcr:primaryType on checked in node* > > If I add the same ACE without the restriction I don't get any error. Is it > a bug or there is something that I don't understand? > > Marco. >
