hi fernando i didn't try it out myself but i can imagine the following behaviour: the check for protection in oak is built on top of the Oak API which already enforces permissions while afaik the same in jackrabbit would operate on the item states, which were not access controlled.
we found similar problems before in the oak-jcr layer and i wouldn't be surprise if there was yet another one :-) may i kindly ask you to file a JIRA issue with a description on how to reproduce the issue. even better if you could attach a simple test-case that illustrates the problem. for the latter you may extend from AbstractJcrTest (from the tck) or from AbstractEvaluationTest present in oak-jcr. kind regards angela On 24/04/15 16:13, "Lemes, Fernando" <fernando.le...@hp.com> wrote: > > Hi guys, > > I'm dealing with some access control problems trying to migrate a >project from Jackrabbit 2.8.x to Oak 1.0. > > I have a user1 sharing a node with user2, but the user2 cannot copy >that node (using session.getWorkspace().copy(<originNode>,<destNode>) >method).. the Oak code checks if the parent for the origin node is >protected, but the user2 doesn't have any permission on that node. Is >this the expected behavior? > > Regards, > >Fernando Lemes da Silva >Software Engineer - Brazil R&D >fernando.le...@hp.com<mailto:fernando.le...@hp.com> >+55-11-4197-8124 >
