On Mon, Dec 19, 2011 at 7:27 AM, Maarten Nieber <[email protected]> wrote: > But the problem is with the permissions, not with the workflow, right? If I > put > my parent node in the 'static' publication state, then the child nodes which > have > inherit permissions' will acquire the permissions related to this static > state. > This is regardless of the workflows that these nodes are using, right? My > objective is that my child nodes do not inherit from the 'static' parent node > (but they should inherit from other nodes).
Clarification: states define permissions only, not local roles, but the permissions might affect how local roles are manifest in different states. That checkbox on the sharing page has nothing to do with permissions, only roles (despite what mis-written help text might suggest). You can block inheritance of specific permissions in the permissions for the workflow states for the definition bound to the child items. But you might well need to block local role inheritance too, I am not sure. You may well need to choose from a variety of slightly-complicated options: 1. Have an after-transition handler on the parent folder do special things to immediate children (set __ac_local_roles_block__ attribute on each immediate child when parent is in static state). Likewise, you would need to reverse this selection upon some inverse transition on the parent, but this risks side-effects. 2. Define a custom PAS local role manager that selectively blocks the acquisition of certain local roles from the parent based on any custom rules you have. This is better in specific situation than the "block all local role inheritance" hammer that is __ac_local_roles_block__. I am in the process of using #2 for a slightly different need (blocking a specific local role name from being inherited in certain cases); I have a hunch that if I was in your shoes I would: (a) set up specific permissions in the workflow for the child items to not inherit (in the permissions tab of the ZMI for the state); (b) create a custom PAS local role manager plugin if that was not in itself sufficient. Sean _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
