Forum OpenACS Development: Re: Permissions Administrator Package
In fact, I'd say it's generally bad practice to ever assign permissions directly to users. If you do, how are you going to keep them all straight?
Relational segments, er, what the heck are those for again? Ah, I see that you and Don more or less explained it back in 2003, Tom. A "relational segment" is either "membership", "composition", or some specialized flavor of those, and is said to be lighter weight (more efficient) than using an OpenACS group.
I still don't see how or why I'd ever actually use relational segments. That's probably just because I never tried very hard to figure them out, but they're certainly rather esoteric and undocumented. Groups, on the other hand, are pretty simple and easy to understand, and they're documented.
Or perhaps I've reinvented the wheel? Is there already a way for a non-technical user to:
- Create a group called News Admins
- Grant admin permissions to all members of the News Admin group on the News package mounted at /mysite/news
- Grant read permissions on the /mysite/ subsite
- Join Joe User to the News Admin group
My package is designed for non-technical client admins to grant access to many regular members for granular access. This is in production on a large non-profit site with a lot of member governance.
Thank you for your comments.
What do other sites with an extensive site map use to control permissions for many users and groups?
1. created a relseg called "content editors" on the membership group for my subsite.
2. granted write permissions on the subsite to members of that relseg.
3. added my content editors to that relseg
All using the existing groups and permissions admin UI.
1. That UI really sucks, and if I didn't know how things work under the hood I probably couldn't use it.
2. The acs-subsite/www/members membership management pages are sorely lacking.
You can think of a relseg as being a lightweight mechanism for making subgroups, for slicing groups into pieces in other words. You can think of the name of a relseg as being a role ... or you can use the role capability of the underlying acs-rels datamodel if you want (the membership management pages might work better if you do, by coincidence I'll be looking into this for some admin pages I'm doing for a client over the next week or two).
This is one area where .LRN actually got things more or less right, using relsegs to define professors, students, etc.
Rocael just posted a suggestion for dotlrn-specific permissions templates which boils down to saying "the subsite ones are insufficient". Dave and I have both suggested that the right thing to do is to fix acs-subsite.
Likewise I think an enhanced UI such as Ryan describes should be built into acs-subsite rather than exist as a separate package.
And, Ryan, I suspect that what you want to do can probably be done with the existing datamodel.
If I have some time I'll try your UI in the next few weeks I hope. I think for now I like the idea of trying to get the UI right, to see what a user-friendly UI might look like, than to worry if you've created some unneeded datamodel bits. If the UI's right, perhaps a couple of us (dave and I, perhaps?) can help figure out how to map that UI to the existing datamodel if it's possible to do so ...
I'd love to see this UI improve.