Forum OpenACS Development: Re: Permissions Administrator Package

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.

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) |
Indexes:
    "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.