The security of a project or folder depends on the permissions that each group has on that resource. The default security settings are designed to meet common security needs, and you may find that they work for you and you don't need to change them. If you do need to change them, you'll need to understand how permissions settings work and what the different roles mean in terms of the kinds of access granted.
Roles
A
role is a
named set of permissions that defines what members of a group can do. You secure a project or folder by specifying a role for each group defined for that resource. The privileges associated with the role are conferred on each member of the group. Assigning roles to
groups is a good way to simplify keeping track of who has access to what resources, since you can manage group membership in one place.
Setting Permissions
To assign a role (a set of permissions) to a group or individual user:
- Select (Admin) > Folder > Permissions.
- Set the scope of the role assignment by selecting the project/folder in the left-hand pane.
- In the image below the Research Study subfolder is selected.
- To grant a role, locate it in the Roles column and then select the user or group from the Add user or group... pulldown.
- Click Save or Save and Finish to record any changes you make to permissions.
Revoke or Change Permissions
- Permissions can be revoked by clicking the x in the user or group box.
- Here we will revoke "Author" permission for the group "Guests" as it was added by mistake.
- You can also drag and drop users and groups from one role to another.
- Dragging and dropping between roles removes the group from the source role and then adds it to the target role. If you want to end up with both roles assigned, you would need to add to the second group instead.
Inherit Permission Settings
You can control whether a folder inherits permission settings from its immediate parent.
- Check the checkbox Inherit permissions from parent, as shown below.
- When permissions are inherited, the permissions UI is grayed out and the folder appears with an asterisk in the hierarchy panel.
Site-Level Permissions
A few specific permissions options are available at the site level, allowing access to certain features by non-admin users:
- Application Admin: Allows control over non-operational administrative settings.
- Troubleshooter: Troubleshooters may view, but not change, administration settings and diagnostics.
- See Email Addresses: Allows non-admin users to see email addresses.
- See Audit Log Events: Allows non-admin users to view audit log events.
- Email Non-Users: Allows emails to be sent to addresses that are not associated with LabKey Server accounts. Use caution when enabling this feature if you have self-sign-on enabled.
- See Absolute File Paths: Allows viewing of absolute file paths from within the filebrowser.
To configure these roles:
- Select (Admin) > Site > Site Permissions.
Permission Rules
The key things to remember about configuring permissions are:
Permissions are additive. This means that if a user belongs to
any group that has particular permissions for a project or folder, they will have the same permissions to that project or folder, even if they belong to another group that has no permissions for the same resource. If a user belongs to two groups with different levels of permissions, the user will always have the greater of the two sets of permissions on the resource. For example, if one group has admin privileges and the other has read privileges, the user who belongs to both groups will have admin privileges for that project or folder.
Additive permissions can get tricky. If you are restricting access for one group, you need to make sure that other groups also have the correct permissions. For example, if you set permissions on a project for a specific team
ProjectX group to No Permissions, but the
Users (logged-in-site users) group has read permissions, then Project X team members will also have read permissions on the project.
Folders can inherit permissions. In general, only admins automatically receive permissions to access newly-created folders. However, default permissions settings have one exception. In the case where the
folder admin is not a project or site admin, permissions are inherited from the parent project/folder. This avoids locking the folder creator out of his/her own new folder. If you create such a folder, you will need to consider whether it should have different permissions than its parent.
Related Topics
