Roles and Permissions
User permissions in Space fall into the following categories:
Organization-wide permissions — valid across the entire organization.
Team-specific permissions — valid within a certain team.
Project-specific permissions — valid within a certain project.
Users cannot be issued individual permissions — instead a user can be assigned a Role which has a pre-defined set of permissions.
Space comes with a number of Default roles (described in the table below). Upon the initial registration users are automatically assigned certain basic roles:
If the user is registered as a regular member, they are assigned the Member role.
If the user is registered as a Guest or Collaborator, they are assigned the limited access External User role.
These roles cannot be taken away, and external users cannot be assigned additional roles, however you can convert external users to members and vice versa on an individual bases.
If you need a custom set of permissions, you can modify some of the default roles by adding or removing permissions from a role or, better yet, create an additional custom role that can be assigned to any organization member.
Organization-wide permissions (Valid throughout the entire organization)
Default Role | Description | Note |
---|---|---|
System Admin | Granted to the users in charge of administering the Space installation and/or organization and personnel management (e.g HR). Includes all available rights in all areas except for Projects. | This System Admin role cannot be edited. Instead, the system administrator can create a new Role with a custom set of permissions. |
Member | This role is issued by default to all users initially registered as Members. It defines the base level of permissions that are available to every member of the organization. Specific permissions that are not enabled for this role can be granted separately at the team or project level. | This role is permanently assigned to all members and cannot be revoked. System Admin can modify the Member role by adding or removing some of the permissions. |
Member Self | This role defines which permissions are available to members for the purpose of editing their own records. | The Self role cannot be modified. |
External User | This role defines the lowest possible level of permissions. This role is automatically granted to all users registered as Collaborators or Guests and cannot be taken away. It defines permissions that are available to every External User (either Collaborator or Guest) in the organization. Collaborator and Guest roles have the same permission set on the organization level. However, Collaborators can be provided a wide range of permissions within a certain project, while Guests can be provided permissions for a limited number of project features: Documents, Issues, Issue boards. This role defines the lowest possible level of permissions.
External Users have limited visibility.
| These roles are permanently assigned to all users registered as Collaborators or Guests - they cannot be revoked or modified. |
External User Self | This role defines which permissions are available to External Users for the purpose of editing their own records. |
Team-specific permissions
Default Role | Description | Note |
---|---|---|
Team Admin | Intended for a team supervisor. Includes the rights to add/remove team members, approve membership requests, create and edit sub-teams. | Team Admin and Team Lead roles are granted on a per-team basis, hence the permissions they contain are only valid within a particular team. Similarly, the Manager role only gives authority over the subordinate members. System Admin can modify these roles by adding or removing permissions. |
Team Lead | Intended for the team lead authorized to approve absences of the team members. Includes the right to see the team members' reasons for absence (hidden to others). The Team Lead and Team Admin roles are typically assigned to the same person. | |
Manager | Intended for a person who is explicitly assigned to another person as their supervisor. Includes the rights to view and approve absences of subordinates and to see their reasons for absence (hidden to others). |
Project-specific permissions (Valid within a particular project)
Default Role | Description | Note |
---|---|---|
Project Admin | Initially granted to the user that creates the project. Intended for project participants that should be allowed to manage access and configure project modules as well as contribute to the project. | Space Projects are self-serviced — any user can create and administer a project. System Admin has no specific rights over projects created by other users. System Admin can modify the default templates for these roles or create a new template with a different variety of project access permissions. The role templates can be then used by Project Admins to create roles for their projects and assign those roles to their project participants. |
Project Member | Granted by the Project Admin to project participants that are expected to contribute to the project on regular basis. Project members form the Project Team and have access to internal project tools and resources. | |
External Collaborator | Defines a limited set of permissions that can be enabled for users registered in the organization as Collaborators and added to the project. Permissions from this set can be enabled for each External Collaborator individually and will be only valid within this project. | |
Guest | Defines a limited set of permissions that can be enabled for users registered in the organization as Guests and added to the project. Permissions from this set can be enabled for each Guest individually and will be only valid within this project. | |
Organization Member | Granted by default to all organization users. Includes viewing rights for some project resources. | |
Automation Service | Granted to Automation scripts. Includes the rights to: |