[Zope-CMF] A very long permissions list ;-)

Danny William Adair Danny@Adair.net
Tue, 10 Apr 2001 11:45:45 +1200


>>> I'm glad you saw this.  We've struggled with this.  In fact, it's worse
>>> than this: you often want to be able to change security based on object
>>> state, such as allowing a user to edit a page when it's in the "private"
>>> state but not when it's in the "published" state.  But you want this to
>>> be a site-specific decision.  So you get (m * n * o) permissions!
>>> Here is our plan: the configurable workflow will take over the role ->
>>> permission -> method mappings.  There are several current views on the
>>> specifics, but essentially the workflow will manage security.  Workflows
>>> can manage security in more flexible ways, such as allowing access to
>>> methods based on object state.
>>>
>>> Questions?

Is this "configurable workflow" CMF-specific? Sorry if this is a CMF faq...
and hit me if it's a Zope item!

I'm very unhappy with the current implementation of the ZMI permissions
page.

I'm not sure if this can be done easily, but wouldn't it all be easier if a
role-permission mapping could be something like a "rule", acquirable of
course? One of my Zope installations takes a couple of seconds to load - on
the local machine - and I wouldn't be much happier with a "permissions
btree", for one simple reason: I only need this whole bunch of permission
mappings *once*. After setting things up, there's only one thing that I (and
I guess most members of the zope community) actually want to do:

change one or two permissions, through methods (seems to be easier said than
done - at least a satisfyingly fast solution -, see my new post on zope and
zope-dev. any idea?)

either based on another permission mapping, or on some user input. Although
I don't know how to access and change a single permission without running
through the complete permission_settings, I guess the latter is not that
hard. So in the event of "publishing", a publishing method could also change
the "edit" permission at the same time, programmatically. Unpublishing would
do the same in reverse. I think this is a common scenario.

Would it make sense to enable the user to place a method like

hasRole(self, Role) on a permission and something like
hasPermission(self, Permission) on a role,
(for every object of course, and acquired)

in order to have a do-it-yourself way of finding out a permission mapping?
That way it would be easy to synchronize a permission mapping with another
one, avoiding the m*n*o scenario.

Invoking hasRole(self, Role) on the "Change x" permission of a folder (and
therefore on all of its underlying objects)

could just

return hasRole(getPermission('View'), Role)

or maybe even something like

return (container.publishing_status=='published')

And if you don't place a method there, things would just be done exactly
like they're done now. With a little redesign the ZMI pages for permissions
wouldn't get too crowded either, imho.

What do you think about this? Or should I just pull my head out of my Danny?

I would like to put a more readable suggestion on zope-dev because I think
someone with more zope security skills than myself could implement something
like this in a day or two. I just don't want to annoy people with something
that doesn't make sense, so I really welcome your comments on this.

I think it really is time to get some magic in the permission part of zope.

Thx in advance,
Danny

P.S.: btw: try the word "programmatically" on hotbot, and guess who's second
and forth on the results :-)

P.P.S.: Why does he know? Why did he try?  <|:-D


>>> -----Ursprungliche Nachricht-----
>>> Von: zope-cmf-admin@zope.org [mailto:zope-cmf-admin@zope.org]Im Auftrag
>>> von Shane Hathaway
>>> Gesendet: Dienstag, 10. April 2001 05:58
>>> An: zope-cmf@zope.org
>>> Betreff: Re: [Zope-CMF] A very long permissions list ;-)
>>>
>>>
>>> Chris Withers wrote:
>>> > Basically, as I see it, each meta_type has a list of actions
>>> associated with it.
>>> > These are currently each assigned a permission:
>>> > 'Add news item'
>>> > 'Edit news item'
>>> > ...etc...
>>> >
>>> > So, you end up with n * m permissions in each system where n
>>> is the number of
>>> > actions and m is the number of content/meta types.
>>>
>>> That's right.  The model of mapping methods to global permission names
>>> leads to this.
>>>
>>> > As an observation, many of the actions can be factored out to
>>> be the same:
>>> > 'Add x'
>>> > 'View x'
>>> > 'Edit x'
>>> > 'Manage x'
>>>
>>> Note that the CMF now uses simpler permissions: "Modify Portal Content",
>>> "Add Portal Content", etc.
>>>
>>> > This there any way this could be factored out at the Zope or
>>> CMF level to make
>>> > lief easier and quicker? Has it been done already? (just in
>>> case I missed
>>> > something...)
>>>
>>> I'm glad you saw this.  We've struggled with this.  In fact, it's worse
>>> than this: you often want to be able to change security based on object
>>> state, such as allowing a user to edit a page when it's in the "private"
>>> state but not when it's in the "published" state.  But you want this to
>>> be a site-specific decision.  So you get (m * n * o) permissions!
>>>
>>> Here is our plan: the configurable workflow will take over the role ->
>>> permission -> method mappings.  There are several current views on the
>>> specifics, but essentially the workflow will manage security.  Workflows
>>> can manage security in more flexible ways, such as allowing access to
>>> methods based on object state.
>>>
>>> Questions?
>>>
>>> Shane
>>>
>>> _______________________________________________
>>> Zope-CMF maillist  -  Zope-CMF@zope.org
>>> http://lists.zope.org/mailman/listinfo/zope-cmf
>>>
>>> See http://www.zope.org/Products/PTK/Tracker for bug reports
>>> and feature requests
>>>