Forum OpenACS Development: Re: Ideas for using groups to minimize custom permission

Collapse
12: Re: Ideas for using groups to minimize custom permission (response to 1)
Posted by Dave Bauer on 04/01/04 03:53 PM
Lars,

The reasoning for my design was to limit administration of an object type under a context. The context would most likely be a subsite. It could be a folder instead. The key is that there is a group that "owns" the folder by having a certain relationship to the folder. The application then grants all rights to that group or relational segment within that group.

The key is that we don't have an ownership concept in openacs, so I guess this is one way to do it.

I think it is a good idea to also be able to grant permission by object type, so the concepts are complementary.

Collapse
23: Re: Ideas for using groups to minimize custom permission (response to 12)
Posted by Lars Pind on 04/05/04 04:30 PM
"I think it is a good idea to also be able to grant permission by object type, so the concepts are complementary."

I inteded this as a solution to your originally stated problem, though, so I see them as two possible solutions to the same problem.

In my proposal, you could grant "admin" on objects of type "news_item" on a subsite, and it would cascade to all specific news_item package instances as usual, and thus be scoped to both the subsite (or wherever you decide to grant it in the containment hierarchy currently implemented by context_id) *and* it will also let you scope to specific object types.

If you do the "object type proxy object" and grant permissions on that, then you'd be granting the permission site-wide, which, to me, doesn't really cut it -- I want to be able to host multiple separate sites on one instance/DB for ease of maintenance.

I do see that your proposal works with the existing permissions system, whereas mine proposes to make a change to that existing system to fulfill a requirement, which has surfaced time and again.

I specifically am not very hot on the thought of having packages do this automatically, so a default install will have a group per application, and maybe even a group per application per subsite. Or maybe even more? What if you want to grant "write" or "create" or "read" or some other privilege? Then you'll want to have a "News Readers", "News Creators", "News Writers", and "News Administrators" groups for each application x subsite on your site. Was that what you were thinking?

/Lars

Collapse
25: Re: Ideas for using groups to minimize custom permission (response to 23)
Posted by Tom Jackson on 04/05/04 05:31 PM

Lars, in response to your last paragraph: you only need one group, probably per mounted instance (for instance privileges), or per subsite (for subsite wide privs). But each grant 'write', 'read', 'admin' would need a separate rel_type (only three for an entire OACS installation). Checking for the membership type in a certain group would be the same as checking the permission to do an action. But I think having the 'write' membership on a news package would not imply I could change someone elses posting, that would be handled by direct permissions on the news object itself. But if a certain membership is required to access a page where administrative functions are available, you don't need to look at direct or indirect permissions on objects.

At any rate, if you can create a site which somehow knows the difference between data for one subsite and the next, it is obvious you can construct a unique proxy object, or group membership, hopefully automatically, that can be used to do what Dave suggests.