Section 15.2.2 of the JCR 2.0 specification has the relevant bits:
When a versionable node is checked in, it and its subgraph become read-only. The effect of read-only status on a node depends on the on-parent-version (OPV) status of each of its child items.
When a node N becomes read-only:
- No property of N can be added, removed or have its value changed unless it has an on-parent-version setting of IGNORE.
- No child node of N can be added or removed unless it has an on-parent-version setting of IGNORE.
- Every existing child node of N becomes read-only unless it has an on- parent-version setting of IGNORE or has an on-parent-version setting of VERSION and is itself versionable.
So, given the parent node (variable 'a') has a primary type of "A", and that the "b" property definition on node type "A" is defined to have an on-parent versioning attribute of "VERSION", then it should not be possible to add or remove children. However, once the "b" children do exist, they are themselves versionable and must be independently checked in.
I seem to be able to add and rearrange child nodes to/on a checked in node which in my mind is a change to the versioned state of the node.
This is not valid, and should be reported as a bug. I just check the JCR TCK, and I can't seem to find a test case that covers this case. (Shocker!)
I cannot delete nodes from a checked in node.
The error I get on the b.remove() line is:
javax.jcr.version.VersionException: '/node' (or its nearest versionable ancestor) is checked in, preventing this action at org.modeshape.jcr.JcrNode.doRemove(JcrNode.java:118) at org.modeshape.jcr.AbstractJcrNode.removeShare(AbstractJcrNode.java:2415) at org.modeshape.jcr.AbstractJcrNode.remove(AbstractJcrNode.java:2458) at au.com.infomedix.documentstore.cnd.TestLoadCND.main(TestLoadCND.java:88)
I agree that this behavior is correct.
If I try to set an attribute on node B after adding it to A (the commented out setProperty call) then I get the same error but for '/node/b'. Having B extend mix:versionable or changing the version attribute on b from "version" to "copy" doesn't make any difference.
Yeah, it seems like whether the 'b' node has a 'mix:versionable' mixin (or having the "B" node type extend 'mix:versionable') should change the behavior. If 'b' is not itself versionable, then the current behavior seems to be correct. (This is because of the last bullet in the quote above.) However, once the 'b' node is made to be versionable, then you should have to check it in before the node is made to be read-only.
Let me sleep on this. If we're correct, then I'll log the issues tomorrow.
I've logged these errors as MODE-1401, and have already fixed, tested, and merged the changes into the official Git repository. The issue has been closed, and the fixes be in the 2.8 release (due before the end of the month).
Thanks again for reporting this.