Forum OpenACS Development: Re: Permissions Administrator Package

Groups are indispensible, I agree, and I've used them in this package. You can join users to a group when you assign them to a role. The trouble with groups is, there's no easy interface for granting object permissions to a group. That is one of the things this package can do.

Or perhaps I've reinvented the wheel? Is there already a way for a non-technical user to:

1. Create a group called News Admins
2. Grant admin permissions to all members of the News Admin group on the News package mounted at /mysite/news
3. Grant read permissions on the /mysite/ subsite
4. 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.

Well, in a site I'm working on I ...

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.

However:

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.