On Tuesday 20 November 2001 14:10, Ian Bicking wrote: > On Tue, 2001-11-20 at 16:27, Tavis Rudd wrote: > > > > * concept of both users and groups (completely separate from > > > > the OS!) > > > > > > Yes, calls them roles. > > > > Ah, but 'groups' are not the same things as 'roles'. I'm using > > 'groups' in the traditional unix sense of the term, but with the > > proviso that a group can belong to other groups. 'roles' are > > something completely different. A better term for 'roles' is > > 'actions'. In the context of web publishing, actions could > > include the following: view, edit, delete, rollback, publish, > > hide, etc. > > > > example: members of group X are allowed to view object Y, but not > > edit/delete/etc. it. > > I'm not clear on what you are thinking. Roles (to UserKit) are > things like, oh, "editor", "contributor", etc. Groups are > equivalent.
Let's scrap the term 'role' completely then, and only use the terms of users, groups, actions and permissions. Where 'actions' are things like view, edit, etc. and permissions are the authorization for particular users and groups to be able to perform those actions on an object. An application designer should be able to define custom actions. And how about the term 'resource' rather than 'object'? We also need to clarify the distinction between 'ownership' and 'permissions'. In Unix these concepts are directly tied together. Not so in NT and other OSes. It should be possible for multiple users and multiple groups to have permissions to do perform various actions on a resource, just like in NT. But then who owns the resource? Should there be a concept of ownership built directly into the system, where only the owner of a resource (and root) can changes permissions for that resource. > > Permissions (aka authorization) are a layer on top of the > > authentification system, so maybe we should start there. I did a > > whole bunch of this stuff (several thousand lines) in PHP before > > I got sick of it and moved to Python. I'll see if I still have > > it sitting around somewhere. > > Well, we can start with authentication if it means we just use > UserKit, because using code that exists is very easy :) If it's suitable. > 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. I think that's going to be very context specific. Pages with distinct URI's are objects, but what about the UI components inside those pages. That's something that best left up to the application designer. > Zope has a very clear notion of what objects are, but then some of > what falls out of that is what I didn't like about it. Ditto!! _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
