Forum OpenACS Development: Proposal: Removal of unnecessary custom permissions

As per Don's suggestion in this thread:

https://openacs.org/forums/message-view?message_id=60252

I would like to initiate a discussion on removing the large number of unnecessary custom permissions in OpenACS.

The main benefit of doing this is to simplify and unclutter the permission's namespace (really, what is the difference between read and news_read anyways?)

The main disadvantage that I can think of is that you would not be able to assign site-wide privileges for all instances of a module (ie, granting "news_admin" to "jo" at the subsite level gives him/her site-wide administrative privileges for any and all news modules that inherit permissions).

I have a modified version of news with the custom permissions stripped out and it works fine.  One issue that needs to be studied further are the upgrade scripts for permissions.  In this example, it would be dangerous to blindly convert all "news_admin" permissions to "admin".  What's the best way to handle this?

So, is this a good idea?  If so, should we make it a goal for the 4.7 release?  Thoughts please.

Thanks...

Collapse
Posted by Jeff Davis on
I definitely think both an audit of the toolkit to check that permissioning is being done properly and a cleanup of some of the permissions that are too fine grained is a good idea.

That said, we need to excercise some care that in the process we don't turn OpenACS into a toolkit that is only suitable for small organizations. Leaving aside the fact that the admin pages shouldn't really be in admin (which is what prevents having news_admin actually work as expected), I can certainly see a larger site wanting to allow someone to admin all instances of news in a subsite but being unable to grant them admin on the subsite.

I think you want the permissioning granularity to be pretty fine since going from fine -> coarse is a matter of changing some data (permissions inheritance etc) but going the other way means changing code. You don't want to say to a large site that needs fine grained permissions that you are going to have to change code in most of the packages to support their needs. Not to mention that doing this adds some appreciable risk that you get it wrong.

I don't really find the custom permissions to be a big problem from a development standpoint, and for a small site granting base permissions (admin, read, etc) on the root generally works as you would expect.

The real issue is the UI for permissioning and browsing permissions is a huge trainwreck. I suspect if we spent a little time on this we would collectively feel much less inclined to remove quite so many of the permissions as we are now.

Collapse
Posted by Lars Pind on
So the use-case for keeping news_admin, forums_admin, etc. is that "someone might want to grant admin on all instances of the forums package under some site node," is that it?

In other words, granting privileges based on the package type.

May I suggest two alternative implementations:

1) Add a column 'package_type' to acs_permissions, so you can say that "when I grant this 'read' permission, it's only meant to work on packages of this type." That's a much better model for the problem at hand.

2) Build a UI to do granting/revoking of those privileges for specific package types. If the use-case is uncommon enough, I think it's a much better solution than burdening the rest of the world with all those privileges.

But I don't believe in the use-case. Can we see a show of hands from people who are actively working on real-world in-use systems, where the use-case above is a real requirement coming from real users of the system?

If such people do exist, I'd very much like to hear the details of their requirements and user story.

And if it turns out that the use-case is indeed fairly common and legitimate (i.e., not just a bad solution to a problem that has an obviously better solution), I'll bow for the facts. :-)

/Lars

Collapse
Posted by Alex the Dog on
<blockquote> But I don't believe in the use-case.
</blockquote>

Sharenet people, speak up!

A.

Collapse
Posted by Jeff Davis on
The root of my problem with removing many of the _admin permissions is that as it stands granting admin on acs-subsite allows a user to do an awful lot of things that you would not want them to be able to do if all you really want is to allow them to administer content on the subsite. Maybe the best answer is to split admin into admin and admin_content where admin_content would not allow the owner to mount packages, delete groups, etc.

Anyway, I think there needs to be an intermediate permission between full admin rights (which lets you do all kinds of things that could break the site) and admin which allows you to administer content in the context of an existing site and can be given to users who don't know quite so much about OpenACS.

Collapse
Posted by Lars Pind on
Jeff,

That makes perfect sense to me.

I don't know if this would be called "moderate", perhaps?

Though I'm not certain where the line should be drawn, the concept is definitely sound.

/Lars

Collapse
Posted by Dave Bauer on
Lars,

The application can decide where exactly to draw the line. I had a few months ago suggested a "publish" permission. I am not sure the name is that important as its place in the hierarchy.

Collapse
Posted by Lars Pind on
Dave,

Yes, I'm aware that the application decides when and what to check permissions for, but some degree of consistency between packages would be nice, no? ;-)

/Lars

Collapse
Posted by Robert Locke on
Currently, with the modified news module (no custom permissions), I explicitly have to grant "admin" privileges to a specific user or group per instance.  For our sites, this is acceptable, and personally, I find it cleaner and preferrable to having the unnecessary custom permissions.

But granting "admin" permissions per module instance wouldn't be necessary if we had a "publish" permission which lies somewhere below "admin".  Great idea!

Though, what exactly would be the difference between "write", "create", and "publish"?  We should have some consistency in the meaning of all permissions across the entire system, as Lars suggests.

The idea of granting privileges to the package *type* as opposed to package instances is intriguing.  But I think it might be confusing and complex to implement inheritance from the site node tree as well as from the package type.

Collapse
Posted by Dave Bauer on
I think generally the permissions should be used like this:

create allows the user to enter a new item.

write includes create and allows editing of that item.

publish is used where an item needs to be approved before
posting, such as news, or a moderated forum.

Having a publish or moderate privilege allows you to have someone manage a package, but will not allow them to change permissions on it, change parameters, or delete the package instance.

Collapse
Posted by Rich Graves on
We absolutely agree with the use case. PR people can not be trusted with technical changes, and technical people shouldn't be posting press releases.

We want to be able to delegate sitewide news, polls, surveys, etc. to area specialists without worrying what else they (or an XSS or IE bug hijacking their account) might be able to do.

In the dotlrn case there may be an actual legal requirement to keep subscriber information compartmentalized.

Collapse
Posted by Robert Locke on
<blockquote> We absolutely agree with the use case. PR people can not
be trusted with technical changes, and technical people
</blockquote>

Agreed, but we don't need all these custom permissions to adhere to that principle.

If we added a "publish" permission (or "admin_content"), then any site administrator could easily implement your policy at the package or site-wide level.

If we could arrive at a consensus on the standard permissions and their meanings (perhaps it's just: read, write, create, publish, delete, admin), maybe we could make it a 4.7 requirement that all package maintainers re-visit their modules and rework their permissions code (certainly some custom permissions will survive, but many will be unnecessary).  Also, I'm still not sure of the best way to handle upgrades.

Personally, this is not a huge issue in that the current system isn't giving me any big headaches or anything.  It just would be nice to see a cleaner and more consistent permissions model moving forward.

So, what's the next logical step?  Who can actually decide on this?

My only issue with news_admin v. admin (not counting related bugs) is that *moderate* or *news_content_approver* needs to separated from *news_parameter_changer* or *news_permission_granter*.

And I think that this is true in most other modules as well, particularly where there is a workflow cycle like news.

Regards..

Collapse
Posted by Dave Bauer on
Roger,

That is exactly why we want a generic publish/moderate admin seperate from the install/paramter admin privilege.

Having a generic privilege at this level will cover almost all cases we can think of and simplify the permissions across most packages.

Collapse
Posted by Jade Rubick on
Late to the game, but I also find the use-case useful, and I think the "publish" level of permissions would be a good solution.

I think the permissions is one of the most confusing aspects of the administration of a site that I've come across so far, and this would be a good fix for it.

Collapse
Posted by Robert Locke on
For now, so that this thread is not forgotten, I have added a comment on the 4.7 project status page located at:

https://openacs.org/projects/openacs/4.7/project-status

Hope that's ok...