When you join a mabl workspace, your user role defines your level of permissions. Depending on your team’s needs and security requirements, you can assign user roles more broadly for shared resources or create more granular permissions using resource groups.
This article defines user roles and permissions at the workspace level and the resource group level.
Workspace roles
There are three types of workspace roles in mabl:
- Owners have full control over the contents and members of a workspace, including adding workspace users and assigning their roles creating resource groups, enabling workspace support access, and changing session duration. If you create a workspace, you become the owner of that workspace by default.
- Editors can make changes as they see fit to shared resources and the resource groups that they are members of. This role is ideal for users that plan to create and run tests in the workspace.
- Viewers can see the content of shared resources and the content of resource groups that they are members of. They can also trigger local runs. Workspace viewers cannot add, delete, or modify tests or trigger cloud runs.
Excluding resources that are part of resource groups, the following tables list the specific permissions for each user role in a mabl workspace:
Tests
Owner | Editor | Viewer | |
Create and edit tests | Yes | Yes | No |
Run tests locally | Yes | Yes | Yes |
Run tests in the cloud | Yes | Yes | No |
Stop test runs in the cloud | Yes | Yes | No |
Credentials
Owner | Editor | Viewer | |
Create credentials | Yes | Yes | No |
View credential secrets | Yes | Yes | No |
Copy credentials | Yes | Yes | No |
Edit credentials | Yes | Yes | No |
Delete credentials | Yes | Yes | No |
API keys
Owner | Editor | Viewer | |
Create API keys | Yes | No | No |
View API key secrets | Yes | No | No |
Copy API keys | Yes | No | No |
Edit API keys | Yes | No | No |
Delete API keys | Yes | No | No |
Branches
Owner | Editor | Viewer | |
Create branches | Yes | Yes | No |
Merge branches | Yes | Yes | No |
Delete branches | Yes | Yes | No |
Commenting on tests and flows
Owner | Editor | Viewer | |
Add comments | Yes | Yes | No |
View comments | Yes | Yes | Yes |
Resolve comments | Yes | Yes | No |
Unresolve comments | Yes | Yes | No |
Resource groups
Owner | Editor | Viewer | |
Create resource groups | Yes | No | No |
Assign users to resource groups | Yes | No | No |
Delete resource groups | Yes | No | No |
Resource group roles
When a workspace owner adds resources to a resource group, access to those resources depends on your assigned resource group role:
Resource group owner | Resource group editor | Resource group viewer | |
View the resource | yes | yes | yes |
Edit the resource | yes | yes | no |
Delete the resource | yes | yes | no |
Use the resource | yes | yes | yes |
Similar to workspace owners, resource group owners can also:
- Edit the resource group
- Add resources to the resource group
- Remove resources from the resource group
Conflicting resource group roles
Resources can be part of multiple resource groups. If a user is part of multiple resource groups with access to the same resource, access will default to the more permissive role.
For example, imagine that a credential is in two resource groups: resource group A and resource group B. If a user is a viewer in resource group A and an editor in resource group B, that user will have editor permissions for that credential.