Forum OpenACS Development: Re: Permissions Administrator Package

Posted by Ryan Gallimore on
In my package "role" is an administrative structure stored in the p_admin_roles table. It's simple a way of containing and representing a set of instructions associated with that role.
Instructions for each role are stored in p_admin_instructions.
See my sql file for more info.

For example, the Role Builder feature in the package creates a role named "News Admin" and then you add permissions like "Admin on the /news package" or "Join Site News Admins Group".

Once the role is created, you map users to the role so they inherit the same permissions above.

The general idea is to make complex administration by non-SWAs easier.

Posted by Tom Jackson on
Right, the OpenACS privilege/permission/user/group system is pretty big with lots of moving parts. Usually roles (or what permissions to require) are defined by the package writers and is pretty domain specific.

You are reporting that your package adds new functionality that may or may not relate to the permissions system, and appears to go around the existing methods of determining object access, but you also say it just helps administer permissions. If you can break down the relationship between your package and the existing permissions system in terms of the data model and existing permission functions, that would help evaluate your package.

Since this is a developers forums, we all understand, or should, the current code and data model. Just relate your package to what we already know.

Role and instructions are unknowns. Also unknown is what data is involved and how it is to be used, can the new system only be used with AJAX? My thought is that the behind the scenes action is more important for evaluation than the UI, considering that the general idea is to turn over an administrative task to non-SWAs. Overall I sense this is a backdoor to existing package data. Hopefully not.

Posted by Ryan Gallimore on
Hi Tom,

You can think of the package as a frontend for permissions. Instead of being object based, as it is currently, it is user based.

Instructions are either an implementation of a direct permission or a join group call.
ie. either permission::grant or group::add_member

So p_admin_instructions represents the arguments required to execute these procs.

                                        Table "public.p_admin_instructions"
     Column     |         Type         |                                    Modifiers
 instruction_id | integer              | not null default nextval('public.p_admin_instructions_instruction_id_seq'::text)
 role_id        | integer              |
 object_id      | integer              |
 privilege      | character varying(6) |
    "p_admin_instructions_pkey" PRIMARY KEY, btree (instruction_id)
    "p_admin_instructions_inst_idx" UNIQUE, btree (role_id, object_id, privilege)
    "p_admin_instructions_role_id_idx" btree (role_id)
Check constraints:
    "invalid_privilege" CHECK (privilege::text = 'read'::text OR privilege::text = 'write'::text OR privilege::text = 'create'::text OR privilege::text = 'admin'::text OR privilege::text = 'none'::text)
Foreign-key constraints:
    "p_admin_instructions_role_id_fkey" FOREIGN KEY (role_id) REFERENCES p_admin_roles(role_id)
    "p_admin_instructions_object_id_fkey" FOREIGN KEY (object_id) REFERENCES acs_objects(object_id)
Roles are then a container for these instructions.
And Roles can be attached to users.

AJAX is currently required just as a way of making object and user selection easier.

I'm not sure what you mean as a "backdoor to existing package data". It is more of an improved interface for modifying many permissions and group memberships at once.

Posted by Gustaf Neumann on
ryan, i am as well a little confused about your terminology. is your implementation user-based or role-based? what is an "instruction"?

Are you able to express what you did in the terminology of RBAC? Here is a good introduction of RBAC:
You might check as well we did on implementing RBAC in: