On Feb 9, 2011, at 2:41 PM, frank rittinger wrote: > Thanks, Jan and Sebastian, > > dispatching a second workflow for a specific path and with another group did > the trick. > > Although it feels a bit strange that publishers and editors are not separated > by access rules but only by the visibility of the Inbox. Wouldn’t it be able > to craft a Request that activates changes without seeing it in the Inbox?
That really depends on what you want. In common scenario, editor can start the workflow as well (by starting activation) so in this case he needs to be able to access workflow and start it. Once the workflow is started, the task of approving the activation will be dispatched to the members of "publishers" group only so even if editor sees the inbox it would be empty. If you want to prevent your editors from accessing workflow all together (therefore having them not able to even request activation), you can deny editor access to workflow related workspaces (Expressions, Store) and to the workflow module node (config:/modules/workflow). If you want some more fine grained control inside of the workflow itself, you can direct the flow based on the user groups or user names or have additional commands invoked in the workflow to retrieve any kind of custom data you might need. HTH, Jan > > Best Regards, > > Frank > > Von: [email protected] > [mailto:[email protected]] Im Auftrag von Jan Haderka > Gesendet: Freitag, 21. Januar 2011 08:27 > An: Magnolia User-List > Betreff: Re: [magnolia-user] Workflow permissions > > In order to be able to activate a content, user needs to have a write > permission on the content. So by setting permissions for the editors you can > control what content they are able to edit (and activate). > > The type of items that publishers see in the inbox is controlled by the > workflow itself to which group of users is given item dispatched. As > Sebastian already pointed out in his answer, you can do so either via > modifying existing workflow and dispatch to different group in case content > belong to the subtree that requires special handling or you can have > completely separate workflow for given subtree. > > Third option you have is to modify the command chain and write your own > dispatcher command that can have any sort of custom logic you can imagine for > deciding which workflow to invoke. > > Alternatively you can extend WebsiteTreeConfiguration class and completely > customize activation menu entry. > > HTH, > Jan > > > On Jan 20, 2011, at 11:07 AM, frank rittinger wrote: > > > Hi list, > > we have a group of users that should only be able to publish a subtree of the > whole website. > > Is this achieved by changing the workflow definition for activation or can > this be achieved by adding roles in the security configuration. > > I couldn’t find the permissions that allow activation. I think the groups > editors and publishers created by the workflow module are only concerned > about the inbox. > > Not to forget ... > The default editor and publisher groups (and roles assigned to them) control > indeed look of AdminCentral for the their members and give write access to > the editors and read only access to the publishers for the website content. > > > > Best regards, > > Frank > > _____________________________________________________________________ > > Vorstand: Ralf Heller, Udo Mobes > Vorsitzende des Aufsichtsrates: Kirsten Heller > Sitz der Gesellschaft: Gruenwaelderstrasse 10-14, D-79098 Freiburg > Amtsgericht Freiburg HRB 6218 > > Versand am 20.01.2011 11:07 von rittinger frank > Validation-Code: 2723005510003 > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
