Hi, If I had to do that I would probably model the ACLs for those state changes on application level (in your Workflow engine), not in the repository.
But if you really want to do it in the repository I see 2 possible ways: 1. model the states as child nodes of the item in workflow, e.g. | -item -- draft Then, you could probably use wild card ACLs such that e.g. only a given group can remove nodes named “draft” and add nodes named “approved”. 2. another possible approach is to add your own SecurityProvider (Angela would know what the actual name is) that evaluates writes based on your logic. HTH Michael On 13 Oct 2014, at 18:58, TALHAOUI Mohamed <[email protected]> wrote: > Hi, > > Most probably for the states. > What about enforcing allowed transition and permissions ? > Ex : > state cannot change from DRAFT to APPROVED > only users with "approve" privilege can set the state to APPROVE > > What would be your recommendation here ? > > Thanks > > -----Original Message----- > From: Michael Marth [mailto:[email protected]] > Sent: lundi 13 octobre 2014 17:43 > To: [email protected] > Subject: Re: questions > > Hi, > > My use case is very basic, I need to bind some LC states to a node type > (something like DRAFT, PENDING, REJECTED, APPROVED) and allow a node to > follow LC transition in response to a user action or a workflow action. > > I would simply add a property with those values to these nodes. Would that > work? > > Cheers > Michael
