Re: plone permissions manual

I agree with you JoAnna that the permissions are hard to understand.

I'd say that if you're using the ZMI to set permissions instead of  
creating roles or workflows via zcml then you're in for trouble as  
workflows can come in overtop and wipe out your zmi security settings.

but this is symptomatic of a larger problem that the plone security  
system is split up between changing workflows, customising a workflow,  
sharing tabs, roles (for users and groups) and zmi security tabs.   
Knowing what to use when and what the consequences can get mind bending.

Just now I had to make a simple change to make all content visible  
only to members.
I had a choice between
a) Intranet workflow
b) Intranet/extranet workflow
c) Set all content private and share viewer role with all logged in  
users at root sharing tab.

In the workflows it's not shown in the UI what the exact difference  
between Internal Draft and Internally published is. After  
experimenting it seemed that my Collage won't display to logged in  
users in "internal draft" so I had to switch to Extranet workflow and  
use "Internally published".

Point is it's got too many choices and hard to predict.

Another usecase I've been meaning to look into is how to create a role  
or group that can add/remove users but have no other "site setup"  
access.

I suspect there are some potential clever UI solutions that could help  
here
For example

- Some quick tryout tool to see what something looks like after a  
sharing/workflow change for any particular role.

- introspection that somehow produces a description of what is enabled/ 
disabled by a state/role. e.g. Internally published=editible by owner,  
viewable to members, hidden from anonymous.

- tighter integration of sharing and workflow UIs

or perhaps it's easier to just document it and the pain will force us  
to think of a better solution :)

On 18/09/2009, at 4:50 AM, JoAnna Springsteen wrote:

>> The audience for this manual
> definitely isn't end user but you shouldn't have to be a programmer to
> understand it either.
>
>
> This will not be a manual for developers or for programming
> permissions. It's for understanding default permissions and what they
> do. It will focus on what to expect when you change a permission for a
> certain role. No ZCML, no generic setup profiles. No programmatic
> manipulations of permissions. Just you and the check boxes in the ZMI.
> I don't doubt that something more advanced is needed, but that is not
> my goal here.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Plone-docs mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plone-docs


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf