Permissions and Roles
There are several systems that determine which users can view and edit specific content in LOGS or perform certain administrative actions:
Each user has one or more roles that determine their access to LOGS
Each project can have individual permissions set to allow specific users to view or edit content in that project
Most users have full permissions on content they created themselves or datasets they claimed
Roles
Each user can have one or more roles, though for almost all cases a single role is sufficient. The roles in LOGS are predefined and cover different use cases. But the roles are very general, for fine-grained access control to LOGS content the project-based permissions should be used in addition to roles.
The predefined roles are the following:
Global administrator
The global administrator has full access to LOGS and can view and modify all content. They can also create and edit users and grant those users additional permissions. This role should only be given to trustworthy users, it grants full access to every aspect of LOGS
Privileged user
A privileged user can view all content in LOGS, but only edit their own content or content in projects they were granted access to. They can not edit the administrative sections of LOGS like persons, instruments or data sources. This role is intended for typical users in a setting where they should be able to view all content. It is not possible to hide content from this user, but they are still limited in which content they can edit.
Regular user
The regular user has less access than the privileged user. They can only view unclaimed datasets, datasets they claimed themselves and datasets in projects they were granted access to. All other aspects are the same as for the privileged user
Restricted user
Restricted users can only see datasets in projects they were granted access to. They can only edit content if they were granted edit permissions on the relevant project.
Read-Only user
The read-only user works the same as a restricted user, but they cannot edit any content at all.
In general, only the people setting up LOGS and managing the administrative parts like user creation or data source configuration should receive the global administrator role. Everyone else should have one of the four main user roles.
In an environment where everyone should be able to see all scientific content, the privileged user role is ideal. This role also reduced the administrative effort since no fine-grained permissions have to be managed on a per-project level.
In a setting where you want to restrict read access to scientific content you should use either the regular or restricted user role. The regular role is necessary if you have unclaimed datasets loaded directly from instruments. The restricted role is useful for users that get all their data explicitly assigned to them via projects. In both cases it is necessary to manage the project-based permissions so that these users can access the relevant content.
The read-only user is meant for situations where LOGS is used to distribute datasets, but where users are not meant to add or edit any content themselves.
Project-based permissions
Each project can have permissions associated with it. This is an optional permissions layer for cases where you require fine-grained access control to scientific data. If your users have the privileged user role you do not need this for granting read access, but it still can be useful for granting write access. If you have regular or restricted users it is important to set up project-based permissions for them.
For each project you can set the following permissions individually for each user:
read
add
edit
admin
The read permission allows those users to view all content in this project. The add permission is required if the user should be able to add content to this project. The edit permission allows the user to edit every piece of content in the project, also content they didn’t add themselves. The admin permission gives full access to modifying the project and also editing the permissions for this project and granting more users access to it.
Owner-based permissions
When a user creates a sample or document or when they claim a dataset they become owner of that entity. This allows them to edit their own content, no matter which project it is assigned to. The exception here is the read-only user role which cannot edit content at all.