Forum OpenACS Development: Response to Permissions Hierarchy

I've been thinking about this myself.  It's not really that "read" is too general, because all of the packages involved treat their "special read" privilege as being a synonym for plain old read (that's what defining a child privilege on a one-one basis does - as opposed to a one-many parent privilege like "admin" that grants you read, write, etc in one fell swoop).  If "read" were really too general than each package would assign subtly different semantics to each of their custom "read" privs.

I'm glad they don't, it would be damned confusing!  As it is, only the existence of all these custom "read" perms is confusing.

Anyway ... this topic's come up before but it's worth talking about again as 4.5 nears release.

Here's my conclusion:

1.  Having 500 different "read" privs is bogus, confusing to the implementor and deadly to any attempt to build an generic UI page.  Currently I can assign "cal_item_read" to a "news" object, which is every bit as silly as it sounds.

2.  The hierarchical mechanism should be restricted to defining one-to-many privs like "admin".

3.  Privs should be scoped by object type to a subtree of the object tree.  Pervasive, generic perms like "read" should be bound to "acs_object" (and therefore applicable to all subtypes of "acs_object", too).  Most packages only need generic perms, those that define their own should do so only when the new perm has a different semantic meaning than perms already available to it via perms scoped to the object's parent types.  The CR, for instance, might define "publish" as a perm and all CMS-style packages using the CR could make use of it.  They don't all need their own and there's no need to allow the user to assign the "publish" term to a "user" object (for example).

4. Cutting down the number of different params and the use of the hierarchy would certainly have no negative effect on performance, and possibly could improve performance.  It certainly meets the "do no harm" sniff test in this regard.

5. Scoping to the object_type hierarchy would make the generic admin perm UI immediately more useful.  Rather than being presented a long list of mostly irrelevant perms to choose from, you'd just get the perms that can legally be bound to your object.  Then the only confusion would be the mega-list of parties to assign as grantees that also appears on the page.  Fixing that is beyond the scope of this post :)

This is all post-4.5 stuff.  The scheme I have in mind would provide an easy upgrade path (just scope all perms in an existing 4.5 installation to acs_object) and flexibility for future development.

Since it's all post-4.5 stuff my plan has been to put together a proposal after 4.5 is released, though I've talked about such ideas to a few people here and there during casual conversation and the reaction thus far has been generally favorable.