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...

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

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.

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.

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.

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.

<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?

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.

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...