Roles and Permissions

User Permissions and Roles

Account → Group

An account can be a member of a group. He is either a normal member (member) or, he is an admin of the group (admin).

• Member (member)

  • Can leave group
  • If a group is added to a project or any other resource, a member of the group has access to that resource

• Admin (admin)

  • All of the above plus
  • Can edit group information
  • Can add members
  • Can remove members
  • Can change the role of members (from admin to member, from member to admin) also for himself

  
  

Account → Project

If an account is member of a project, the account has access to the project based on his/her role in the project. An account can be a member of a project with one of the following roles.

If an account is member of a project, the account has access to the project based on his/her role in the project.

An account can be a member of a project with one of the following roles

• Read Only User (read_only_user)

  • Can view the data that is inside the project
  • Can use the analytics
  • Can see running tasks for the project

• Restricted user (restricted_user)

  • All of the above plus
  • Can tag and edit entries inside the data tables
  • Can edit analytics, arrangements etc.
  • Can see crawling profiles of other users inside the project

• Default user (default_user)

  • All of the above plus
  • Can create tasks for the project
  • Can import task results into the project
  • Can add crawling profiles to a project

• Admin user (admin)

  • All of the above plus
  • Can update project information (name, description, icon)
  • Can add and remove members (groups + accounts)
  • Can change the role of project members

Group → Project

If a group is a member of a project, all members (independent of their group membership) have access to the project as specified for the group → project role. The group → project roles are the same as the account → project roles, but they apply for all group members.

If e.g. a group is a restricted_user of a project, then all members of the group have restricted_user access to the project. This can be interesting to e.g. add a legal unit, consisting of multiple accounts, as read-only to a project, so they can see what is happening and make sure everything is legal.

If a member of a group leaves a group or is removed, he/she will not have access to any of the projects anymore, that the group had access to. If e.g. someone leaves the legal unit, the user has no access to the projects that the legal unit group had access to.

If a user is a direct member (Account → Project) and also member of a group that is added to the project, the following prioritization is made:

This allows us to do the following: Let’s say Account A is part of a department-wide group. The whole department should have full access over Project X. But Account A belongs to an intern named “Alan”. He shouldn’t yet be trusted with editing all of the data from Project X. We can therefore add Alan’s account again with a direct membership but this time give him read-only access. Because the direct membership is prioritized we have successfully downgraded Alan’s membership to the project without having to downgrade the whole group.

System Permissions and Roles

In order to manage system administrators, we use django groups. When creating a user, a user is either add into the default group or the admin group. These groups are created at migration-time and are updated every time the migration is performed.

The admin group has all possible permissions. The default group has a certain set of blacklisted permissions.

• Default

  • Can do all things except for the admin things listed below

• Admin

  • Can register new runners as well as remove old runners
  • Can add custom networks
    • Cannot remove internal networks but can disable them
    • Can view disabled networks
  • Can perform CRUD without further checks for any of the
    • Projects
      • as well as memberships of projects
      • data inside of projects
    • Users
      • When changing passwords an admin does not need to provide the old password to set a new one
      • Only an admin can create/register new users
    • Tasks
    • Groups
      • as well as memberships of projects
    • Crawling Profiles
      • yes, an admin can view, edit, delete etc. all crawling profiles of every user