Permission: Difference between revisions
(Created page with "In ContactsLaw, <strong>permissions</strong> to the various features and functions of the software are determined using ''Access Control Lists (ACLs)''.") |
No edit summary |
||
Line 1: | Line 1: | ||
In [[ContactsLaw]], <strong>permissions</strong> | In [[ContactsLaw]], the <strong>permissions</strong> that govern how each [[member]] interacts with the software are determined using ''Access Control Lists (ACLs)''. An ACL is a table containing [[Security:Role|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. | ||
== Effective Permissions == | |||
In determining the ''effective permissions'' for a particular member, ContactsLaw will: | |||
# Determine which role(s) are held by the member. | |||
# 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 ([[Matter|matters]], [[Document:Folder|folders]], etc) need only be defined in exceptional circumstances. | |||
== 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. |
Revision as of 16:51, 28 April 2023
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.
Effective Permissions
In determining the effective permissions for a particular member, ContactsLaw will:
- Determine which role(s) are held by the member.
- 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.
- If so, check whether the ACL grants the permission to any of the member's roles:
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.
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.