Permissions System

This describes the way the permissions system currently works in website v3 (new website).

Permission

The permissions table stores names and descriptions of permissions. It must be noted that you should be VERY careful when naming permissions (and it may even need to be enforced through UI), as a forward slash has a very, very specific purpose. Basically, forward slashes allow permissions to have a scope. In general, this follows the form:

c:Class[/v:Verb][/o:Object][/f:Field]

If any of the scopes (excluding class obviously) are omitted, it is taken that the permission applies to the entire scope (ie. if you omit /f:Field, it is taken that the permission applies to all the fields of the class)

This form is the way that the automatic permission checking is handled. However, custom permissions can be created, and in this case, the slashes form a hierarchy of permissions rather than scopes. Custom permissions it must be noted, mean nothing unless they are checked somewhere in PHP code!

Checking a permission

While the system automatically checks certain permissions, such as whether the current user is allowed to view/edit/create/delete something, you can also check a permission in PHP code yourself by calling:

Auth::checkPerm(permission_name);

PermissionGrants

Permissions are granted to persons or groups in the permission_grants table. permission_id is the id of the permission in the permissions table, grant is a boolean value indicating whether the permission is being granted or denyed. True means that the permission is being granted. Using the rules laid out below, you can restrict or grant access to any granularity required. Only one of group_id or person_id should be set, and should be set to the group or person id of the group or person who is being granted/denyed the permission.

How Permissions are assessed

The permission system works on the basis of "auto deny, grant, deny". This means that when checking a permission, the following logic is used:

(1 - auto deny) If no permission granting or denying access to the resource exists, DENY.
(2 - grant)     If a permission granting access to the resource exists, find the highest priority and lowest scope permission, move to next step, otherwise DENY.
(3 - deny)      If a permission denying access to the resource of equal or higher priority or lower scope to the grant permission exists, DENY.
(4)             GRANT.

This basically means that for a permission to be considered overall to be granted, the highest priority and lowest scope (term explained below) permission must GRANT the permission.

Priority and Scope

Priority is a measure of how specific a given permission is. For instance, a permission specifying both a class name and a verb is more specific than a permission specifying merely a class name, thus has a greater priority. Scope refers to whether the permission applies to a group or a person. A permission applying to a person always takes precedence over a permission applying to a group.

Priority is assigned as a number (automatically calculated, not in the table) based on the sum of the following:

c:Class  = 1
v:Verb   = 2
o:Object = 4
f:Field  = 8

If a custom permission is created, it's priority is the number of levels into the hierarchy it goes, i.e. a/b/c has a priority of 3.