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

[Joachim Werner]

> 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.

Isn't that just a GUI issue? Technically speaking, it makes perfect sense to
me to implement a local "role" of a project manager as a group that is
associated with certain permissions. I think makes the implementation easier
than it is now.

> 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.

Probably groups COULD be placeless in the concept Chris has proposed:
Mr X can be a member of the group "Assistant Administrators of the News
Board", and THAT group is then placefully bound to a certain set of roles in
the news board zone of the site. The confusions comes from the fact that
most acl_user folder implementations now mix up the user source (or group
source if you want) with the binding of the group to a role. So currently
somebody can only BE or NOT BE an Editor or Administrator, but there is no
way of telling the system (without add-on products) that he or she is an
Editor in a certain part of the website.

> 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.

I'm not sure if you really need ROLES. Don't you actually only need what
Zope calls permissions? If you want a fixed set of features to belong to the
same permission, you could either have single permissions for all of them
and group them into a role or just give them the same permission. If,
however, you want to keep things separate, two seperate roles would be
needed anyway, so you can also use two permissions (can anybody still follow
me? ;-)) ...

I think as soon as the code checks for people's roles (which is the case in
the CMF and unfortunately also in Kontentor), something is going terribly
wrong. Code should check for permissions, and permissions can be bound to
users or groups of users.

> 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.

The question is WHERE you are actually going to to the mapping of users to
permissions. My personal opinion is that any basic components of an
application (which is what we do on the Python level) should NOT check
against roles, but use permissions instead.

The mapping of these permissions with the appropriate users or groups is
done on the administration level. There might be a need for a two-level
administrative interface, so on one level only the system integrator can
have access (and predefine groups or roles if you want) and on the second
level the client's administrator can map those presets to actual users ...

> 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.

I see that it might be a good idea in many applications to call the "things"
users can become part of "roles". But I still see no real need for having a
different technical implementation for that ...