OK, from posts on the jackrabbit mailinglist it looks like I should give the Principalmanager a closer look.
Apart from that I wonder if I think in the wrong direction. Maybe there is another way to deal with restricted properties? The example I currently face is a property on a node which holds the "Approver". The approver property contains a reference to the user who has to be notified/approve every change on a node. Normal users can just read that property only a few (manual) selected users can change that property. All the other properties on the node can be modified by all users. When property security is not an option I can only think about introducing a childnode containing the approver information which can be secured with the JCR capabilities. However I already have the requirement to also "protect" three other properties and I wonder what the performance impact might be when splitting the node into a parent and protected children. At every read operation of the parent node I then have to assemble all children to provide a view to the client. And the parent node is requested very often. Any thoughts on this? Thanks, Markus On Mon, Jan 10, 2011 at 10:46 PM, Justin Edelson <[email protected]> wrote: > Well, this is really a question for the JCR EG, but... no, this isn't part > of the JCR specification. > > On Mon, Jan 10, 2011 at 4:39 PM, Markus Joschko > <[email protected]>wrote: > >> Hi, >> I know this question is more appropriate on the jackrabbit mailinglist >> but maybe somebody here can help me: >> Is it possible to define ACLs for individual property actions on a >> node. So that only some selected properties can be modified by a >> specific group of users? >> >> If yes, what are the implications for sling? >> >> Thanks, >> Marksu >> >
