Home
The Toolkit for Online Communities
17707 Community Members, 0 members online, 2418 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Ideas for using groups to minimize custom permission : One Message

Forum OpenACS Development: Re: Ideas for using groups to minimize custom permission

Collapse
Posted by Lars Pind on
It seems there's a couple of use-cases which the permissions system doesn't support, but which it simply should support.

First, you frequently want to grant admin on all *content* of an object, e.g. all bugs in a bug-tracker, without granting admin on the bug-tracker itself. Or admin on all forums and threads, without granting admin on the forums package itself.

Also, the 'grant admin on all news items' has come up time and again.

So how about this: Have 3 types of grants:

- grant on the object itself, but not the child

- grant on the children, but not the object itself

- grant on all children of a certain object_type, but not the object itself.

Before you say "permissions is slow already, this will just make it slower", we have a design at hand which is known to speed things up considerably:

Instead of having one row per (object_id, grantee_id, privilege), like you do today, have a table with a single row per (object_id, grantee_id), and with one column for each privilege in the system.

Of course, that number can fluctuate, but if we just create about 500 spare columns with generic names, that should be good enough for the time being. Plus we want to get rid of custom privs, not add to them.

Branimir has some experience with this, and can help us implement it for OpenACS, and he claims that it made permissions checks a zip.

/Lars

Collapse
Posted by Tom Jackson on

Lars, Huh? You mean there isn't a handy pl procedure to do it, not that the data model doesn't support these three 'grant types', right? Writing this procedure would be just as easy or difficult with your proposed model, wouldn't it? I'm not sure what the extra columns would accomplish other than making it impossible to join (easily) against the table. I think since Don's recent reorganization of the base tables you can do a join to do bulk permission checks, although I haven't tried it myself.

Collapse
Posted by Lars Pind on
Ok, I think I complicated matters unnecessarily by mentioning the single-row optimization. Forget about that, and let's concentrate on one thing at a time.

Requirement:
------------

- I want to grant 'admin' on all news items to user x.

Dave's Design:
--------------

Create a site-wide "News" group, etc. -- see above.

My conceptual design proposal:
------------------------------

Instead of thinking of this as granting privs on *packages* think about it as granting privs on *objects*.

What you want to do is grant 'admin' on all objects of type 'news_items'.

One possible implementations:
-----------------------------

Add a column 'object_type' to the acs_permissions table, which defaults to 'acs_object', menaning this permission is granted on all object types.

Change the permissions check procs/views to also check whether the object in question is a subtype of the value of object_type column in the acs_permissions table.

... there are other possible implementations, if you agree with me on the conceptual design.

Comments?