On Mon, Feb 24, 2003 at 12:41:01PM +0100, Oliver Bleutgen wrote:
From that I gather that your "sites" don't map 1:1 to objects into zope, so that you cannot use local roles for that, right? E.g, there are methods like doTaskX(location,...), where the permission to execute that method depend on location, and location is not an object inside zope.
That is correct.
Well, for me roles are just a simplification/optimization for getting permissions of a user (for an object) for the sake of easier management. From the mapping user_id -> set of permissions, we go to user_id -> set of roles -> set of permissions, where the last mapping is defined by mappings of the form role -> set of permissions. This works, because for typical situations, you just need to define a handful of roles.
i'm with you so far...
Since your application might not be suited for that scheme, it might be worth throwing out roles altogether. How about creating a role for each user (i.e. user "user_id" get's just the role "user_id", instead of creating a role for for each possible (task,location) tuple. When creating a new user, the admin would have to just assign the permissions, instead of roles. This task could be made easier by creating template permission sets.
Interesting idea... tell me if I'm wrong, but I see two obvious problems with this approach: 1) for one-role-per-user: we'd have to visit the security management for N objects in Zope and adjust the permissions every time we add a user. Whereas in my proposal, we only need to do that every time we add a site or change the tasks, which happens much less frequently. 2) for one-role-per-user, changing a user's privileges means wanding around the ZMI setting permissions on N objects. Whereas in my scheme, we can do that in one place (LDAP) by adding or removing a role or two.
You might wind up with less roles and I bet administration is a lot easier.
my guess is that in our case, the number of roles would be comparable. 200 sites * 10 tasks = 2000 roles 200 sites * 10 users = 2000 roles -- Paul Winkler http://www.slinkp.com