For more information read the Permissions System documentation.

The permissions system is conceptually very simple. It allows the programmer to ask whether or not a given party can perform a given operation on a given object.

Since permissions act on parties, one can assign permissions to an entire set of parties (including users) at once. For instance, to allow all members of the predefined "Registered Users" group to be site wide administrators (probably not a good idea!) give that group the "admin" privilege on the permissions root object (since this is a bad idea, finding this object is an exercise left for the reader).

The permissions system support a hierarchy of privileges (described in the next slide).

The SQL and Tcl APIs simplify a variety of common permissions checking tasks:

• A Tcl script can require a user have permission, with an error automatically triggered otherwise:

  permission::require -privilege write -object_id $my_object_id
  

  Return an error if the current user does not have permission to write to the given object.

• A SQL query can return "t" or "f" in its rowset for a given permission (Oracle example):

  select ad_permission.permission_p(party_id => :party_id, object_id => :object_id, privilege => 'admin') as admin_p
  ...
  from your_object_type_table
  ...
  

  Useful for queries that do something like "return all the objects of my type that the user can read, and return an admin_p flag which determines whether or not the user can admin each object as well.

• In SQL, select all the objects for which the user has a given privilege.

  select *
  from my_object_type_table mott
  where exists (select 1
                from acs_object_privilege_map aopm
                where aopm.object_id = mott.my_object_type_table_id
                  and aopm.privilege = 'read'
                  and aopm.party_id = :user_id)