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

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

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.