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.

Resources

• Accounting
  • Members can list any transaction that contributes towards their "recovery" metric.
• Billing
  • Members can list any time records on which they appear.
  • Members can list any orders for external services placed by them.
  • Members can list any invoices that contribute towards their "sales" metric.
• Calendar
  • Members can edit any calendar items for which they are nominated as the organiser. All attendees can view the item.
  • Members can edit any task items they own. All delegates can view the item.
• Contacts
  • Members can edit their own contact.
• Daemon
  • The service account under which the daemon runs can manage any scheduled jobs on the server.
• Documents
  • Members can undo their own checkouts (other members require the "undo checkout" permission).
  • Members can view items in the recycle bin that correspond to documents they originally deleted.
  • Members can delete any temporary documents they uploaded.
• Matters
  • Members can list any matters on which they hold a role.
• Members
  • Members can edit their own profile, excluding details relating to authentication and permissions.
• Processes
  • Members can continue or abort any process they started.

Roles

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, except for the "resolve conflicts" permission.
• The Supervisor role on matters behaves as above, but also grants "resolve conflicts".