Skip to content

Privileges and access levels

Project roles

Every user can have at most one role within each project.

  • Owner: is the creator of the project. Has all privileges for the project.
  • Contributor: is someone who can add/delete/update content of the project (files and datasets). Contributor can also modify some metadata within the project (such as description), but he can not add members to a project, nor can he delete the whole project.
  • Reader: has access to project content (datasets and metadata), but can only read the data.

Roles inheritance and effective role

As project are organized ih hierarchies, automatic propagation/inheritance of roles in the hierarchy tree is applied. As a user you can list projects where you have at least a Reader effective role. You can either inherit this role from parent projects or you can be added by a project Owner as a direct member of a project. Effective role is the strongest role user has in the actual hierarchy

Example of hierarchy with sample user project roles:

  • Site(tenant)
    • Project1 - User is assigned reader role
      • SubProject1
        • SubProject11
      • SubProject2 - User is assigned owner role
        • SubProject21
        • SubProject22 - User is assigned reader role
    • Project2
      • Subproject2 - User is assigned reader role
Project Effective role
Site(Tenant) No role - no access
Project1 Reader
SubProject1 Reader
SubProject11 Reader
SubProject2 Owner
SubProject21 Owner
SubProject22 Owner (Reader is less then Owner)
Project2 No role - no access
SubProject2 Reader

Deprecation note: In November 2022 the Project Access Level property of projects has been deprecated. That means the Access Level property in API is ignored at the input contract and the project access is based on effective role.

Listing root projects

Root projects are virtual projects under the site level. They are virtual because they dont have to be physically placed in the tree under the site level but they are evaluated based on effective roles.

Using the example hierarchy above, the list projects endpoint will return

  • Project1
  • Subproject2

Project2 is not returned because the user has no role assignment for this project.

Project capabilities

Project entities that are returned by the API contain information about the privileges of the calling user with respect to the given project. These are the effective permissions obtained by combining the user group, membership and project access level.

  • CanEdit: indicates the permission to edit project metadata (description, name, etc)
  • CanDelete: indicates the permission to delete the whole project (i.e. move to recycle bin) and restore the project if it already is in the recycle bin
  • CanGrantAccess: indicates the permission to modify membership (user roles) within the project
  • CanCreateContent: indicates the permission to upload data into project (i.e. create datasets)
  • CanListContent: indicates the permission to list datasets within the project (but not actually reading the files)
  • CanReadContent: indicates the permission to access the files/datasets within the project (e.g. download a file)
  • CanDeleteContent: indicates the permission to delete datasets

For more information see Data Admin user documentation: http://doc.mikepoweredbydhi.help/webhelp/mike-cloud/dataadmin/index.htm

Custom User groups

In development.