Status: Closed (View Workflow)
Affects Version/s: 2.7.0.Final, 3.0.0.Alpha1
Similar Issues:Show 10 results
MODE-1141 VersionManager.checkin(...) descends below any versionable nodes within that subgraph MODE-2117 Session#checkPermission should raise an AccessControlException for read-only projections MODE-1226 Allow nodes (and subgraphs) to be detached from the session and reattached to another session MODE-569 Enhance Graph.java's Subgraph object toString() method to show recursive node structure and properties. MODE-704 Attempting to Check Out a Newly Versionable Node Fails MODE-2005 jcr:mergeFailed cannot be set on a checked-in node, in case of a version merge failure MODE-726 Node.checkout() Refreshes the Entire Subgraph under the Node MODE-708 Session.move Performs Version Check on Wrong Node MODE-1966 Registering a repository in a read-only jndi context should not generate an error MODE-2055 Session.getNodeByIdentifier should not return the version history of a node
When checking in a versionable node, that node and its subgraph should be read-only. In particular, 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.
Apparently we restrict the adding/modification/removal of properties (tho we should verify that with additional tests), but we do not restrict the adding or removal of nodes. Additionally, even when the OPV setting of a child node definition is VERSION, the expected behavior differs depending upon whether the actual child node is versionable.
Consider these node types:
and this code:
The a.setProperty("name", "aaa") statement (commented out) is not possible without an exception:
However, the a.addNode("b", "B") should not be possible either without an exception. And once there is a child named 'b', whether its properties can be changed depends on whether 'b' is versionable. Currently, setting a property on 'b' when 'a' is checked out is not currently possible, even when 'b' is versionable.
See the forum post for more context and detail.