...
- There is no inheritance of roles between portal, area, project and entities/servers/applications levels.
- On project level there is "mass user management" functionality available - that allows synchronising user roles from project level to application entities level. This substitutes inheritance where necessary but still gives granularity for projects that need it.
- For security and convenience reasons removing user from lowest role in that particular level automatically removes him from all higher roles on that particular level. For example removing someone from user role removes him also from admin role.
Customer area roles
| Permissions | reader | owner | admin | billing | user |
|---|---|---|---|---|---|
| List projects member of | X | ||||
| Create Project | X | ||||
| List users in CA | X | ||||
| Add user to CA | X | ||||
| Delete user from CA | X | ||||
| Set and change roles | X | ||||
| List invitations* | X | ||||
| View billing | X |
*Only Portal admin can delete an invitation.
...
- x - means that particular role has that particular permission(s)
- green colour - it shows what permissions each person gets when assigning roles as designed (whatever role including all lower roles)
| Application | Permissions | Roles | ||
|---|---|---|---|---|
| Reader | User | Admin | ||
| General | read access | x | ||
| comments possibilities | x | |||
| write access | x | |||
| administration access | x | |||
| Jira project | ||||
| view issues | x | |||
| comment issues | x | |||
| editing issues | x | |||
| moving issues between workflow steps | x | |||
| editing own comments | x | |||
| managing issues | x | |||
| managing versions | x | |||
| managing components | x | |||
| managing project workflows | x | |||
| Confluence space | ||||
| view pages | x | |||
| comment pages | x | |||
| editing pages | x | |||
| moving pages | x | |||
| editing own comments | x | |||
| managing pages | x | |||
| managing templates | x | |||
| deleting anyone's comments | x | |||
| Gitlab project/repository | ||||
| view code | x | |||
| committing code | x | |||
| creating merge requests | x | |||
| approving merge requests | x | |||
| Artifactory repository | ||||
| read repository | x | |||
| write into repository (annotate, deploy, cache, delete,/overwrite) | x | |||
| manage repository | x | |||
| SeedDMS folder | ||||
| read access to folder | x | |||
| write access to folder | x | |||
| manage folder | x | |||
| Subversion repository | ||||
| view code | x | |||
| committing code | x | |||
| Bitbucket repository | Read | x | ||
| Write | x | |||
| Admin | x | |||
Server roles
Notes
- x* - means that it requires additional check on "server roles"
- x** - means that "Server Admin" can manage server user roles up to his role hierarchy - in other words he cannot assign/delete "Server Owner" role
| area admin | area owner | project user | project admin | project owner | server user | server admin | server owner/creator | |
|---|---|---|---|---|---|---|---|---|
| Create server | x | x | x | x | x | |||
| Delete server | x | x | x* | x | x | x | ||
| Add user to server | x | x | x* | x | x | x** | x | |
| Remove user from server | x | x | x* | x | x | x** | x | |
| Change server user role | x | x | x* | x | x | x** | x | |
| Change server state (start, stop, ...) | x | x | x* | x | x | x | x | |
| Change server capacity | x | x | x* | x | x | x | x | |
| Server backups (enabling, disabling) | x | x | x* | x | x | x | x |
In short:
- Server Owner has more privileges when comparing to Server Admin but mostly in hardware management area - so he can delete the server and change server capacity,
- Server Admin is able to manage user roles in server but only for users that are up to his role hierarchy - Server Admin cannot manage Server Owners.