On Wed, 2001-11-28 at 00:27, Chuck Esterbrook wrote: > On Tuesday 20 November 2001 02:10 pm, Ian Bicking wrote: > > It's not at all clear to me, now, what an object is in Webware, with > > respect to permissions -- obviously not every object is going to have > > permission information. Not every object is viewable. > > Geoff and I have played around with some designs for permissions. > Interesting questions came up: > > - Do you ask the user object if he has permission to do X to Y, or do you > ask Y if user U can do X?
You might ask either if they have an opinion, and take the greater (less?) permissive answer. > - How should permissions be archived? Particularly in MiddleKit. > > - Permissions should obviously speak of roles. Should they also be able to > speak of specific users? Well, it's a big pain if there isn't an escape for those few instances when the normal process deviates. While they are seldom long-term, in the short-term user-specific permissions are conventient. > > And how about the term 'resource' rather than 'object'? > > I think this adds another conceptual layer that will obscure more than > enlighten. At least that's my thoughts until I see some text that spells > things out some more. I think the only problem with object is that it is more granular than most (well, all) permission systems are likely to be. Probably every resource will be wrapped in an object, if it isn't already an object, but every object will not be a resource in terms of having permission restrictions. Also, resources may actually be more like a list of parameters and a class -- the resource isn't identicle to the particular instantiated object that represents it at any one time. So you can't use id() to get the ID WTO permissions. > On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote: > > In the more general sense, you might want to have relations. A person > > can "own" something, perhaps another person is the "creator", or > > "manager", etc. I suppose that's what you were thinking of as > > roles...? Ownership could just be another role. > > > > Okay, I think we've got three ideas of roles just in this one email. > > Damn terminology. > > If you're going to say person X is manager of Y, then I think the right > term would be relationship. My idea of permissions though is oriented > towards verbs: X can delete Y. That is so much more immediately obvious. I don't feel it actually fits how things are managed and thought of. I've been thinking from the general and back to the specific about this. I think for most of the stuff I've done, the real permissions come down to something like this: Resources are parts of projects. Users have roles inside with respect to different projects. Permissions are a mapping of role->(resource class, action) The resource classes are a bit fuzzy in my mind yet, but I think this is equivalent to declaring a resource, say, "confidential", "financial", etc. So you might say, oh, accountants can edit financial resources for their department. Editors can edit normal content for their projects. You might also give that person the role of Advisor globally, such that they could add comments to anything (well, not to confidential documents). I feel this comes close to matching how people actually work with documents and such in real life. The other big thing that most permission systems don't deal well with is delegation -- even though it is extremely important. Zope is actually pretty cool this way -- being able to add users specific to particular folders. But anyway, there needs to be a way for one user to say, "for this activity, this person can act with my authority." Capabilities have some ideas about doing this -- well, actually I guess that's how all permissions are aquired in a capabilities-based system. In this case, it would be good to have the specific command "user X can do action Y on object Z as though they were me", but also the ability for there to be a hierarchy of roles, or perhaps of permissions, so that a user can give another user as many permissions as they themselves have. Or something like that. It's something that most permissions systems leave out -- except perhaps through the notion of ownership -- and lack of delegation causes lots of annoyance for users to get to do what they want (and in turn encourages overly permissive systems, since at least then it won't get in the way). The idea of actually going in and finding documents and changing their permissions is painful to me. It won't be done, or to the degree that it is done, it means the permissions will become a mess and no one will be able to figure them out (i.e., audit them) with any ease or through any larger structure. Especially when you are dealing with lots of small resources, ones which users might not even realize are distinct... it's just messy. Then you have to think about what permissions will exist for newly created object, how permissions might be inherited, how you can do search-and-replace for permissions, how you add new groups and give them access en masse, etc. That's why I really don't like ACLs, and a lot of those criticisms apply to capabilities too, since they aren't that different. Ian _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
