setPolicy requires checkout?

[Mat Lowery <ml...@pentaho.com>]

According to the JCR 2.0 API documentation of 
AccessControlManager#setPolicy(String, AccessControlPolicy):

"A VersionException will be thrown either immediately, on dispatch or on 
persists, if the node at absPath is read-only due to a checked-in node. 
Implementations may differ on when this validation is performed."

Doesn't this assume too much about the implementation?  Using Jackrabbit 
2.0.4 defaults, rep:policy's onParentVersion is IGNORE so it technically 
doesn't require a checkout but the implementation actually does make 
sure it is checked out in ProtectedItemModifier.

I'd like to make an ACL modification without creating a new version.  
Any ideas?
<http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/RepositoryException.html> 

Re: setPolicy requires checkout?

[Mark Herman <MH...@NBME.org>]

Angela Schreiber-2 wrote
> 
> 
>> I'd like to make an ACL modification without creating a new version.
>> Any ideas?
> 
> as far as i know this is not possible in JCR.
> 
> 

Not directly, but AFAIK there is nothing stopping you from making changes to
a parent (non-versionable) node which will change the effective permissions
on that versionable. I would consider redoing the design so the structure
matches your security model, so then you don't need to worry about the ACLs
on each of your versionables.  Worst case you could put all of your
versionables in individual non-versionable containers, but that feels dirty.

--
View this message in context: http://jackrabbit.510166.n4.nabble.com/setPolicy-requires-checkout-tp4493029p4493578.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: setPolicy requires checkout?

[Angela Schreiber <an...@adobe.com>]

hi mat

On 3/21/12 6:06 PM, Mat Lowery wrote:
> According to the JCR 2.0 API documentation of
> AccessControlManager#setPolicy(String, AccessControlPolicy):
>
> "A VersionException will be thrown either immediately, on dispatch or on
> persists, if the node at absPath is read-only due to a checked-in node.
> Implementations may differ on when this validation is performed."
>
> Doesn't this assume too much about the implementation?

i don't think so. it's just a matter of when the VersionException
is thrown and a given JCR implementation may not be able to determine
the check-out status of the node at absPath upon the transient
modification.

in the current reference implementation this is possible and
thus any transient modification (setPolicy or addNode) on a
checked-in node will immediately fail.

> Using Jackrabbit
> 2.0.4 defaults, rep:policy's onParentVersion is IGNORE so it technically
> doesn't require a checkout but the implementation actually does make
> sure it is checked out in ProtectedItemModifier.

well, the onParentVersion setting is another story IMO as the
API contract only refers to the checked-out status of the node
at absPath, which in this case is versionable and unmodifiable
as long as it is not checked-out.

> I'd like to make an ACL modification without creating a new version.
> Any ideas?

as far as i know this is not possible in JCR.

kind regards
angela