[Zope3-dev] Re: a note on groups and roles

[Phillip J. Eby]

At 06:01 AM 3/24/02 -0500, Chris McDonough wrote:

>I want to be able to grant a set of permissions to a group of users.
>Whether that group of users is called a role or a group is not that
>meaningful of a distinction to me. ;-)  I understand that there is some
>defacto jargon centered around roles as collections of permissions and
>groups as collections of users and that this jargon is starting to gel.  I
>just want to raise a red flag at this point to say that I don't understand
>why it needs to be this complicated, seeing as we're essentially starting
>from scratch and no other system that I can think of has this particular
>combination of (extensible) collections.

There is an extremely important use for roles that are *not* groups.  A 
person may be a project manager of five projects, but not of ten others.  A 
"project managers" group is useless for granting the user permissions 
relative to his five projects.

Now, if you want to call that a "local group", I'm sure you could.  But 
that's not what most workflow and content management systems call that 
concept.  They call it a *role*, as in the "project manager role".  And 
those workflow systems use roles to define permissions.

I've never had a problem with the concept of roles, from my first encounter 
with them in Principia many years ago, because of this perspective.

A role is usually defined by application data.  If you're listed as the 
project manager on a project object, that implies your role.  In most 
security systems, groups are extrinsic, tied to the system rather than to 
data, and exist in a "placeless" fashion.

IMHO, it is going to be harder to teach people about "placeful" groups, 
than to use existing CMS and workflow terminology for "roles".


>I'm not sure why my suggestion doesn't solve the problem you mention.  The
>indirection in my suggestion happens as a result of being able to nest
>groups, which you currently cannot do with roles right now.  This inability
>drives normal people insane because they need to do the same thing over and
>over again in different places.  This is why everybody is crying for another
>layer of indirection.  They need to shoehorn it in to the current Zope 2
>model, so they are thinking in terms of roles, but it doesn't need to be
>this way. ;-)

I'd rather have groups be placeless, the way they are in the vast majority 
of systems that I've encountered.  It might be nice to have them nestable, 
the way they can be in LDAP, where a group can be a member of another 
group.  But that's optional to me.


>Example: you define a group at the root.  You assign a set of users to the
>group.  You visit a folder and create another group, which includes a
>"local" set of users as well as the group you defined at the root.

In a folder-oriented view of the world, this makes some sense.  From a web 
applications perspective, it doesn't.  As an application developer, I need 
roles much more than I need groups.  If I can compute roles, I can 
supplement it with my own group system if I need it.  Part of Zope 3's 
goals, as I understand them, is to make Zope more usable for corporate 
applications development.  Corporate applications developers need roles, 
and the more complex the application, the more roles they need.

I am really violently opposed to replacing the term "role" with "group", 
because it's a widely used term for something that I *don't* really need or 
want.  And it's *much* harder to get somebody to assign a new meaning to a 
word they already know than to give them a word which either they know from 
another context (workflow or content management), or don't know and thus 
realize they have to learn.