Forum OpenACS Development: Proposal: Removal of unnecessary custom permissions
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.
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.
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.
Sharenet people, speak up!
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.
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.
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.
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?
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.
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.
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.
be trusted with technical changes, and technical people
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?
And I think that this is true in most other modules as well, particularly where there is a workflow cycle like news.
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.
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.
Hope that's ok...