Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: error (athena.apache.org: encountered temporary error during SPF
 processing of domain of piccinatto@ibest.com.br)
Date: Thu, 12 Sep 2013 06:05:43 -0700 (PDT)
From: hsp <piccinatto@ibest.com.br>
To: users@jackrabbit.apache.org
Message-ID: <1378991143523-4659526.post@n4.nabble.com>
Subject: Granted permission to remove operation
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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-operation-tp4659526.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.