Overview of Permissions
- Helen Williams
What access (or permissions) a Slate user has can be controlled by multiple variables within Slate, which are broadly categorized into:
User Access - What system tools or features can the user access? (e.g., the Reader, Deliver, etc.)
Record Access - Which records can the user access? (e.g., all records, only application records, only records added to a certain population, etc.)
Object Access - What database objects can the user access? (e.g., specific queries, deliver campaigns, forms, events, etc.)
By combining the tools provided across all three categories, very detailed and graunular limitations can be placed on an individual user and what they are able to do within the system. It can often seem that there is much overlap between the tools used to customize the specific permission/access a user has. For example, system permissions refer to access to tools (Deliver) as well as records (Application Lookup).
It can be helpful to think about what tool the user is accessing vs. what records they are accessing vs. what objects they are accessing. For example, the ability to look up application records is the system permission, and which records can be viewed is a record access question. So a user must be given the system permission to use the lookup tool to have the ability to look for records, but a record access permission (usually via population) can then be added to limit the specific records they can view. Similarly, to access the Query tool a user must have a system permission to Queries, but which queries they can open and view could be limited by an object permission (realms).
Depending on the complexity of the database, adding record access or object access permissions may or may not be necessary, but user access permissions are fundamental and required.
User Access
Slate has two primary “types” of user permissions – standard and exclusive.
Exclusive permissions are unique; they have security implications and are excluded from assignment through “inherit;” they must be added intentionally and should be reserved for admin users only.
System permissions are the “main” type of permission; they grant access to the majority of the records, tools, and functionality within Slate. These permissions are further broken into two categories:
Population-capable permissions - permissions that can be given to users that will be inherited for records in a selected population, as opposed to all records.
General permissions - permissions that can be given to users that will be inherited for all records, regardless of population.
KB Article overview of https://knowledge.technolutions.com/hc/en-us/articles/360050427751-System-Permissions#permission-descriptions-0-1
Custom permissions are unique to each database/instance and are added/created by admins to control access to many different objects in Slate. They must be created, assigned to the object, and then assigned to a user/role in order to work.
Roles
Granting permissions through a role allows for the ease of adding or removing specific permissions for multiple users because they will update across any user who has been assigned that role. It is also a great way to consistently grant the same set of permissions for each user carrying out the same role.
Additionally, a user can have individual permissions layered on top of those that are inherited from a role. For example, a user may be granted a faculty reader role but is also the events coordinator, so they may be granted the individual permission of Events (edit all users).
Record Access
notes from Helen’s research into population permissions done in 4/2023 using KB and webinars.
A population in Slate is just a label for a group of records. Population rules are used to define and enroll records in the population.
The scope of the population will determine which kind of rule can add records to the population.
Population-capable or population-aware permissions are permissions that can be given to users that will be inherited for records in a selected population, as opposed to all records. They are included within the system permissions master list, but only a sub-set of system permissions are population-capable.
How to Grant/Use Population Permissions:
Use the populations tab on the user account
Permissions granted in the permissions tab will override the population restriction, so don't add the 10 population-aware permissions on the permissions tab
Can grant either individually by permission or through role
User will inherit any population capable permissions in the role for the selected role and the other non-population aware permissions (functional permissions) in that role will also be granted (don't need one role for functional and one for population-aware)
Can grant access to more than one population at a time
Once applied:
Users can only get access to records in a granted population, can use the universal search and may see names of non-population records but won't be able to go through all the way to the record.
In reader, will only see application records that belong to a certain population. Can still see bins, because that's controlled by permission settings on the bin, but won't see the records (will show 0)
In release decisions, will only be able to assign, confirm, and release decisions on records enrolled in a granted population.
Roles or permissions assigned from the "roles" tab are not population-aware.
Object Access