Private project access guidelines
Managing project visibility and access helps you control who can view, edit, or collaborate on your projects. With the right settings, you can keep sensitive project assets private while still enabling effective teamwork where needed.
Permission definitions
- Read permissions
- Read permission provides the capability to view project details only.
- Write permissions
- Write permission provides the capability to do administrative and operational actions on a
project, such as,
- Create
- Update
- Delete
- Import (by using API)
- Export (by using API)
- Publish
- Deploy
- Git-related operations
Roles based on project ownership
Access control is the same for both administrator and developer roles. The only exception is that administrators can view all projects, including private projects, and can change the ownership of any project. However, access is controlled based on ownership or collaboration.
The following table outlines the different project roles and the permissions that are assigned to each.
| Role | Assigned project permissions |
|---|---|
| Owner | Read, Write |
| Collaborator (Read) | Read |
| Collaborator (Write) | Read, Write |
Roles and permissions
- Permissions are evaluated based on the assigned project role, not user type alone.
- Write permission implicitly includes read access.
- Private projects are accessible only to explicitly assigned users.
- Write and read permissions do not include execute access.
- Custom roles are applicable for private projects.
Effective permissions summary
| Role | Read (View Project) | Write (CRUD and Operational Actions) | Execute |
|---|---|---|---|
| Administrator – Owner | Allowed | Allowed | Allowed |
| Administrator – Collaborator (Read) | Allowed | Not allowed | Allowed |
| Administrator – Collaborator (Write) | Allowed |
Allowed Cannot delete the project |
Allowed |
| Developer – Owner | Allowed | Allowed | Allowed |
| Developer – Collaborator (Read) | Allowed | Not allowed | Allowed |
| Developer – Collaborator (Write) | Allowed |
Allowed Cannot delete the project |
Allowed |
| Custom Role (Read) | Allowed | Not allowed |
Allowed If the user has Execute permissions for that project |
| Custom Role (Write) | Allowed |
Allowed Cannot delete the project |
Allowed If the user has Execute permissions for that project |
Ownership rules
- The first user (Administrator or Developer) who creates or imports (Git repository) a project is automatically assigned the Owner role.
- The first user (Administrator or Developer) who imports (by using API) or deploys a project is automatically assigned the Owner role.
- Project owners have full control over the projects.
- Project owners or administrators can transfer the project ownership.
- Project owners can manage collaborators.
- Administrators cannot manage collaborators.
- Project owners or administrators can switch a project from public to private mode.
- Administrators are not allowed to edit project assets but can view them.
- Project owner and collaborators who have write access can edit private projects.
Collaborator rules
- Collaborator permissions are limited to the assigned access level (read or write).
- Collaborators cannot transfer ownership or manage collaborators.
- Collaborators cannot delete projects.
Key points related to role change and multiple roles
- If a user’s role is changed, then the privileges applicable to the new role come into effect. For example, if a user role is changed from administrator to developer, then developer access privileges come into effect.
- If a user has multiple roles, then the resultant roles are as follows.
- Administrator, developer equals to administrator.
- Administrator, custom equals to administrator.
- Developer, custom equals to developer.
- Administrator, developer, custom equals to administrator.
- If an administrator or developer becomes a custom user and owns a private project, the user retains ownership of the private project unless an administrator removes the project.