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

[Phillip J. Eby]

At 12:12 AM 3/27/02 -0500, Jeremy Hylton wrote:
> >>>>> "PJE" == Phillip J Eby <pje@telecommunity.com> writes:
>
>   PJE> At 10:06 PM 3/24/02 +0000, Florent Guillaume wrote:
>   >> - Roles are really groups of permissions.
>
>   PJE> No, they aren't.
>
>   PJE> A role is an application-domain relationship between a user and
>   PJE> an application--domain object, which *implies* a set of
>   PJE> permissions.
>
>I don't see a difference here that has any impact on the way groups of
>permissions would be implemented.  We can decide to all call a set of
>permissions an "application-domain relationship between a user and an
>application" but it's still just a set of permissions.

That's between a user and an "application-domain object".  There's a 
*world* of difference  between what I said and what you just said.


>How would this distinction have an impact on implementation?

Because a "set of permissions" carries no implication that it is the 
application that grants that set to a principal, rather than the 
infrastructure doing so.

If we call a "set of permissions" a "SOP", then the requirements I have 
regarding them are:

1. Allow individual application objects to grant SOPs to principals

2. Zope should ask application objects *only* for SOP's needed by the 
current principal to carry out their immediate intentions

3. SOP's are definable by applications for use within their "placeful" 
space, without conflict with SOP's in use in other spaces

It is not at all clear to me that these requirements would be clear if we 
are talking about just "sets of permissions".  A "set of permissions" does 
not imply the forward and backward translation awareness that is required, 
for example, by requirements 1 and 2.

If we did not use the term "roles", it would not make sense to speak of 
applications granting them *as* sets of permissions.  If I say, "objects 
can grant principals a set of permissions", this does not clearly indicate 
that the object can grant something that implies other permissions, unless 
we are going to say that all permissions allow transitive implication.

However, that is not (as I understand it), what you and others have been 
saying about roles.  Mostly what I've been hearing is, "roles are 
meaningless, they should go away".  It is *because* you think they are 
meaningless that I am arguing for them!

By that, I mean that so long as the word "roles" exists, you still know 
that there is something you don't understand about what people want from 
the concept of roles.  As soon as you banish the word, you'll all be able 
to begin forgetting about the requirements that go with it, because there 
will be nothing there to disturb your mental models of how the system 
should work.

What I'm saying is that I don't care about the word "role" per se.  What I 
care about is keeping my requirements for roles visible.  Every year or two 
this "let's get rid of roles" argument comes up, and I pop up out of my 
little corporate developer hole to say, "Hey, I'm using that, it's an 
important feature...  and while we're discussing this, it'd be nice to make 
it so that I don't have to hack the User object to get incremental role 
discovery."

So, if you want to get rid of "role" as meaning a set of permissions, then 
it needs to be replaced with something else.  So far, the arguments I've 
seen have been only that it *could* be replaced, and therefore should go 
away.  What I'm saying is, there'd darn well better be a replacement picked 
before you get rid of the only placeholder for the concept, and any 
requirements not implied by the new terminology should be formally added to 
the architecture, so that the folks who live in "folder world" don't drop 
out the stuff needed by us folks who often don't use even one folder 
besides the root in their entire Zope instances, and have other Zope apps 
that don't even use ZODB.