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

The more specific the resource, the fewer permissions are governed by the ACL; for example, workgroup ACLs may govern matters and documents, whereas folder ACLs may only govern documents.

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 the roles held by a member. It is not possible to deny such permissions using ACLs.

• 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".

Reduced Requirements

When a member has a direct relationship with a particular resource (e.g. a document they uploaded), the requirements to interact with it may be reduced. It is not possible to deny such interactions using ACLs as no permissions apply.

• 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.