Permission

In ContactsLaw, the permissions that govern how each member interacts with the software are determined using Access Control Lists (ACLs). An ACL is a table containing roles and the permissions granted to them in respect of a particular resource. The resource may be a subscription, business, workgroup or some other item.

Scope

ACLs can be defined on the following resources:

• Subscription (global permissions)
• Business
• Workgroup
• Matter
• Folder

Effective Permissions

In determining the effective permissions for a particular member, ContactsLaw will:

1. Determine which role(s) are held by the member.
2. Check whether there is a specific ACL associated with the resource requested by the user:
   • If so, check whether the ACL grants the permission to any of the member's roles:
     • If so, permission is allowed.
     • If not¹, permission is denied.
   • If not, determine the item that owns the requested resource (if any) and repeat from step 2.

In this way, a handful of ACLs defined on high-level resources (subscriptions, businesses, etc) determine the permissions that apply in most cases, while ACLs on low-level resources (matters, folders, etc) need only be defined in exceptional circumstances.

Note that workgroups are hierarchical; therefore, a workgroup may "own" one or more child workgroups for the purposes of permissions.

¹ If a role is absent from the ACL, it is not granted the permission.

Implicit Permissions

Some permissions in ContactsLaw are implied from existing data and therefore do not need to be granted using ACLs; e.g. a member can always view their own profile. It is not possible to deny such permissions using ACLs.

Additionally, some roles also implicitly grant permissions:

• The Administrator role grants all possible permissions. It should not be held by members who use the software on a daily basis.
• The Manager role on matters grants full permissions to the matter and any resources owned by it.
• The Supervisor role on matters behaves as above.