Permissions and access control¶
There are multiple levels of user permissions available in CATMAID. All of them
are configured from within the admin interface, reachable by appending
/admin
to your regular CATMAID URL and opening it in a browser.
Permissions can be given to either users or groups. Users can be members of multiple groups and using them makes user and permission management often a little bit easier.
Project access and visibility¶
Users can access projects through either the top menu bar, a front page (data
view), a deep link or directly through the API. Which projects users can see and
access by these means is determined by whether they have can-browse
permission on those projects.
To view and change project permissions, open a project in CATMAID’s admin view
and click “Object permissions” in the upper right corner. There it is possible
to add either individual users or groups to the various permissions that exists
for projects (including can-browse
).
If users or groups have can-annotate
permissions they are allowed to create
new data (e.g. neuron reconstructions or ontology classifications) in a project.
This permission also makes it possible to edit data that was created by other
users. However, for this another test comes into play as well and not every user
can edit the data of all other users. See next section for more details.
The can-administer
permission provides access to additional group management
and user analysis tools, mainly useful for group managers. It will add
additional tools to the statistics widget in the web-client.
The anonymous user is with respect to project visibility a special case. If a
project should be publicly visible, the anonymous user needs to have
can-browse
permissions on the project, but another permission is needed as
well: in the anonymous user’s own user settings the general “catmaid | can
browse projects” setting has to be assigned. With this, the anonymous user acts
just like a regular user and can be assigned project specific can-browse
and
can-annotate
permissions.
In total there are seven different permissions CATMAID understands with respect to projects:
Permission |
Description |
---|---|
|
Edit various project wide settings and view user statistics. |
|
Write to a project by creating e.g. tracing data or annotations. |
|
Read data from the project, needed see the project and look at it. |
|
New data can be imported into a project, either from files or remote sources. |
|
Tasks like large project data exports can be started. |
|
Write operations are allowed through the API. |
|
Personal copies of projects (only stacks) can be created. |
By default, no permission is assigned. All of them can be assigned to users or groups like described above though.
Inactive users¶
Users who are marked as inactive won’t be able to log into CATMAID. Once reactivated, these user accounts are fully functional again. By default, users have to be marked inactive manually. It is however also possible to automatically deactivate user accounts after a specified time. If Celery and Celery Beat are set up, a periodic task will check every night if user accounts need deactivation.
Which user accounts get deactivated is configured based on which user groups they are in. Group Inactivity Periods are objects that associate a user group with a maximum inactivity time as well as an optional message and (internal) comment. During activity check, the last login of a user is looked up and compared against the specified maximum inactivity time. If the last login exceeds this interval, the user account is made inactive. These Group Inactivity Periods can be managed in the respective admin view.
For each Group Inactivity Period contact, users can be specified, who are displayed to users who have been inactivated due to this mechanism try to login. A message displayed to them explains the situation and how long the inactivity period is they violated.
Editing data of other users¶
Users with can-annotate
permission on a project can create new data and by
default, users can’t edit data of each other. However, they are allowed to to so
if they are member of a group with a name matching the data creator’s login
name. So user A can edit user B’s data if user A is member of a group named B.
Superusers can edit data of everyone.
Additionally, there is the special case of imported data. When skeleton data is imported from a remote source, CATMAID will try to keep the original creator and editor information in tact. With the rules above, this can possibly have the effect that the user who imported a skeleton can’t edit it or even remove it, if it was imported by accident. This happens if the importing users has no permission over data of the users who originally created the imported skeleton. To avoid this, there is the following extra rule: a user who imported a node or skeleton has full permissions over it, just as if it was their own. No permissions are granted this way on the imported data of other users. However, if user A has imported data and user B has permission on that user’s data (by being in user A’s user group), user B will also have permissions over the imported data.