hi not sure that i understand what you are saying. jackrabbit does check for sufficient permission to remove a node or property in the run of the save call.
as far as i understood you are having your custom implementation of the access manager and run into troubles while upgrading to a more recent version. can you provide a test that illustrates the problem? kind regards angela On 9/12/13 3:05 PM, "hsp" <[email protected]> wrote: >I am facing a "issue" in my rules when a user in the session invokes the >node.remove(). >The api did not call the "isGranted(Path absPath, int permissions)" in >this >invoke to remove(), but when the user calls session.save() the >"isGranted(Path absPath, int permissions)" method is entered but the >item/properties is not there anymore and the operation is permited and >saved, but the user was not with that permission to remove the node... so, >how to check the remove permission when the ItemManager will not find to >node to check this (this happens independently if the user has or not the >remove permission). > >I did a call to "checkPermission" before invoke the "remove" as a >workaround, but I think the api would check this on demand by the >org.apache.jackrabbit.core.security.AccessManager implementation, not??? > >I am doing my own rules to achieve the rights for the user, and my >implementation was based on version 1.4, and now after upgrading to 2.6.3 >I >needed to adequate the levels of permissions and methods of the interface >AccessManager, but it seems that the api changed the way to check the >permissions and it is not like in version 1.4 at least for the >"node.remove" >method. > >I will apreciate any directions of help, >Regards > > > >-- >View this message in context: >http://jackrabbit.510166.n4.nabble.com/Granted-permission-to-remove-operat >ion-tp4659526.html >Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
