From: Ian B. <ia...@co...> - 2001-11-21 05:25:22
|
On Tue, 2001-11-20 at 23:11, Tavis Rudd wrote: > > That's not what I was hoping for: that still means there has to be > > a group editor_of_book1, editor_of_book2, etc., while I'd like > > "editor" to be a role that is specific for a certain object (book1, > > book2, etc). [...] > Ok, I see what you're getting at now. In that case, a 'role' is a > set of permissions to perform certain actions on an resource. Users > and groups that are given the 'role' editor for a resource are > allowed to edit but not delete it. By allowing a group to belong to > other groups you get this behaviour. What you're suggesting would > internally be implemented like this anyway ('editor_of_book1'). The > question then, is whether the implementation details should be hidden > from the user. I suppose roles (or whatever -- I don't have a word for quite what I was thinking about) could be implemented as groups. You could have an editor group, to which editor_for_book1 would belong. But I don't want to have an editor_for_book1 group at all. I guess what bothers me about that is that book1 is local to some context -- the books section or whatever -- but editor_for_book1 is global. If every local permission issue has to be resolved with changes to the global permission system (i.e., by adding a group), then it discourages sufficiently granular or accurate localized permissions. > > I think there needs to be more opportunities for abstraction in the > > permission system. Also, a more declarative model might be easier > > to manage. > > More declarative in what sense?? Well, the process to deal with ACLs is usually procedural -- when something happens, you (or your script) go in and manipulate the ACLs just so, to represent whatever happened. A more declarative way would have permissions be more rule-based (where rules might rely on data structures). So when you wanted to express an abstract change of permissions -- like, uh... designers should be able to edit any .tmpl files -- you would add a rule that would say just that, as opposed to doing a chmod like operation. When you can express intentions, I think the result is much more manageable. OTOH, it's easier for people to understand concrete operations... > > > > I don't think ownership is a necessary metaphor, though > > > > sometimes it is a useful metaphor. Sometimes it is > > > > meaningless. > > > > > > I agree that in most cases the concept of ownership will be > > > meaningless, but some of the AppIdeas on the Webware Wiki would > > > need this concept. So it's best to build it into the base > > > system. > > > > I don't think things should be built in because they might be > > needed -- instead we should build a structure where they can be > > implemented as needed. I don't want everything to have an owner > > just because a few things need ownership, just like everything > > shouldn't have an executable bit, etc. > > I just mean for the hooks to be built-in. That would not require > that everything have an owner. 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. > > > Correct me if I'm wrong, but it seems that UserKit can't be used > > > with non-servlet files. > > > > As far as I can tell UserKit has absolutely no web-based or > > webkit-based assumptions. It is totally seperated. It also > > doesn't address anything to do with permissions, just users. It's > > quite minimal. > > Ok, then so the only way to use UserKit to manage permissions for > non-servlet files would be to call it from the Application class like > I was suggesting. I suppose -- but I don't really see how Application is necessary. You can always just import the module and use it directly. Isn't that good enough? I don't see what Application gives you that plain modules don't -- they are both similarly global. Ian |