If you scrap the roles, then it means you either have to assign people to groups locally, ie local groups, or you must be able to set the

Yes! In the current Zope 2 system, some roles are essentially placeless (ala Anonymous, Manager, Authenticated, Owner... Owner! ;-)) while local roles and user defined roles are placeful. I'd like to be able to get rid of the placeless roles. There's no need for them that I can figure out if you've got a root object somewhere hanging around to stick them on, and the distinction between user defined roles, local roles, and global roles in Zope 2 is particularly painful to explain without typing "homina homina" ;-). Note that if you'd rather call what I call groups "roles", it doesn't matter much to me, there's no distinction between roles and groups to me. At least if there is one, it's almost negligible. Maybe the one difference would be that I would imagine that a role cannot possess another role, whereas a group can contain another group. This is not a limitation I'd like to place on any new system. In the model I advocate, all groups would be considered "local". In the setup I outlined, you would define a group by visiting a place much like you do now in the local roles interface of an object in Zope 2. The act of defining a group would consist of adding users and other groups to the group you're defining. The place could be a containerish item (maybe the root folder) which allowed its subelements to make use of its group definitions via acquisition or composition, or it could be a leaf-level item (maybe a page template), where that particular object is the only object that knows about a group. To define a group, you would be presented with a UI that looked essentially like this (both lists representing multiple select boxes): User Group ---- ------ admin Managers user Editors user2 Reviewers user3 user4 user5 <<Submit>> The userlist presented by the interface would be obtained by traversing down the place hierarchy, asking each user database that is encountered for a list of users, presenting the aggregate list. The group list presented by the interface would be obtained by traversing down the place hierarchy, starting with the object on which you're defining the group, asking each containing object for its list of groups, presenting the aggregate list. You would only be able to perform the user-group mapping if you possessed the permission "Manage Groups" in the place. The list of groups would be filtered by the groups to which you currently belong (so as to not allow you to grant access via a group that you don't already have). You would associate users with groups by selecting one or more users and the groups to which they should belong in this place (and its subplaces), and clicking a submit button. You could not associate users with groups while managing the user object, because it would probably be too expensive to traverse the entire object hierarchy to gather up all the ad-hoc groups attached to all objects below where the user is defined unless you kept a registry (which I understand we're doing in Zope 3 in some way). An important distinction to what I'm advocating is that two users (or groups?) may never have the same short identifier (username). Thus it would be possible to identify a user or group unambiguously anywhere in the system by referring to it by name, making it easy to present an unduplicated and readable list of users and groups without needing to distinguish them visually by the place in which they're defined. Maybe it could also be the case that common containers would always allow the addition of new users to itself (without needing to go through the special gesture of adding a user folder to the container). You would also need to associate permissions with a group in a place, probably somewhere on another form much like the form shown by the Zope 2 "Security" tab. The Security tab would present an aggregate list of all users and groups at and below its place and would allow you to associate each user and group with a set of permissions.

permissions locally, ie local permissions. So your suggestion doesn't obviate the need for local roles, it just creates a need for something other that is local, since you don't have any roles at all, and therefore obviously can't have local roles. :-)

Honestly I don't care whether they're called roles or groups. But I have a tough time understand the need for groups/roles that are not placeful and why we'd want to make that distinction.

I any case: There are a lot of permissions in a Zope system. When adding some more products, you get even more permissions. Roles are a grouping of permissions, and is neccessary to make the permission system mangeable. If you each time you need to locally change the permission settings for a group of a person have to wade through 30-40 permissions and remember exactly what each of them does, you will only end up with giving most people the rights to do almost everything.

This is a whole different can of worms, but I would like to see Zope clearly define a fairly comprehensive "top-level" set of permission objects (e.g. "Add Content", "Change Content", "Delete Content") that act as mini-registries and can be "drilled into" for the ability to have finer-grained control. When developers register a permission, they would register it with one of the top-level permission objects. For example, if someone wanted to register "Change ZWiki Pages", they would register this permission with the "Change Content" top-level permission object. Something like this would allow us to have groups of permissions with a sane starting point. It would also facilitate a much cleaner "Security tab" UI.

The only problem with the Roles system is that people over and over again mistake it for usergroups, since they are expecting usergroups. This can be fixed by having some type of usergroups in addition to the roles. Then people won't think roles are usergroups, read the documentation and see the light.

Well, you're talking to one of those people, so I'm not entirely unsympathetic. ;-)

Also, the Anonymous and Authorized roles should be removed, because these are not proper roles, and may add to the confusion of roles and groups. Anonymous should be a built-in and non-removable principal. If it helps to clear up the roles concept, maybe some other roles like "Author", "Viewer" or "Member" should be created by default. But "Authorized" is a state, not a role.

There is no Authorized role currently.. you probably mean the Authenticated role. I agree that this is kind of a stretch, but it was necessary for a couple of our applications (ala CMF) that must present action lists based solely on roles. Actually, I think having the global role "Authenticated" is no worse than having the global role "Owner". ;-)

...

FWIW, relatedly, I don't understand the use of the term "principal" instead of "user" for the "entity with credentials" in Zope 3.

Neither do I. For me "principal" means "headmaster". :-)

After reading the stuff that Jeremy sent over (which does discuss the concept of a principal), it seems like it may be more common than I though and I maybe just need to do more reading. I'm only opposed to it on the grounds that it's an unfamiliar term to most people, but if it really is common security jargon, then I don't really have much of a problem with it.