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

[Phillip J. Eby]

At 10:11 AM 3/25/02 +0100, Joachim Werner wrote:
> > 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.

That depends a *lot* on the implementation.  If the system doesn't allow 
you to compute groups relative to *every* object, it *won't* be the same as 
a role system.  Calling it a role makes it clear that it is relative to an 
object and is not an entity in itself.

Say "group", and what comes to mind?  A group of people that exist in their 
own right.  Say "role", and what comes to mind?  An abstraction, a part 
that different people could play.  The latter is what I need, not the former.

That's why I oppose a name change; "role" better implies the *requirements* 
of that capability.


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

I really don't care about any of that; I don't use user folders or worry 
about their placement because I don't build "content" sites with Zope.


> > 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? ;-)) ...

If you want to call it a permission, that would be okay, *as long as* it's 
still computable.  Permission has some implication of abstractness, but 
IMHO it's not as clearly a relationship as the word "role".



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

I don't need to check roles.  I need to compute them.  If my code is 
dealing with an SQL database that has a field for the project manager, I 
need to be able to have my code compute and return that the user has the 
project manager role.

In order to do this efficiently, I need to know what role will grant the 
principal the needed permissions, so I only load and check what is 
necessary.  This means that the Zope machinery has to tell my application 
code what roles would be useful.

I can see how this could be simulated if permissions were hierarchical, 
i.e. implied other permissions.



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

Again, it's computing them, not checking them, that needs to be done in the 
application.


>The mapping of these permissions with the appropriate users or groups is
>done on the administration level.

No.  It's done by the application, from its underlying database.  It is 
*not* an administrative function.  This is why I'm being so vociferous 
about my use cases; they do not match the models being discussed here, that 
are being promoted as reasons for dropping the notion of roles.


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

Again, this is almost entirely irrelevant.  Pretty much in my situations, 
if someone's a user at all, they get the same set of global 
permissions.  (Actually, I usually deal with 2 or 3 broad classes of 
access).  The fine-grained permissions are all data-driven, often according 
to fairly complex rules, which require SQL database lookups to sort out.


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

As long as it is computable by the application on an object-by-object 
basis, no, there's no need for a seperate implementation.  Computable, 
hierarchical permissions would probably suffice for my purposes.