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
- SubProject1
- Project2
- Subproject2 - User is assigned reader role
- Project1 - 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 don not 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 binCanGrantAccess
: indicates the permission to modify membership (user roles) within the projectCanCreateContent
: 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.