Permission Management
CodeArts Repo provides a permission model that contains the tenant, project, and instance levels.
The application scope of this model is as follows: tenant-level permissions > project-level permissions > instance-level permissions.
If the permission configuration in this model conflicts, this permission priority is used: instance-level > project-level > tenant-level.
Tenant-Level Permissions
These permissions take effect for all projects in the current tenant, including creating, deleting and modifying projects, and creating workspaces.
By default, users with the Tenant Administrator permission have tenant-level permissions. You can also grant project permissions to users without this permission. To authorize other accounts, perform the following steps after logging in to the CodeArts homepage:
- Log in to CodeArts homepage and click the username in the upper-right corner.
- Choose All Account Settings.
- Choose .
- Select Set some members to be able to create projects. The member list is displayed.
- Toggle on or off
to enable or disable the authorization. Unauthorized members cannot create projects.
Project-Level Permissions
These permissions take effect for the current project, including editing and archiving projects, configuring roles and permissions, and configuring members. You can also configure operation permissions for each service, including the permissions to create, submit, and copy raw requirements in CodeArts Req, and the permissions to commit and merge code in CodeArts Repo. These permissions take effect for all instances of the service.
CodeArts provides role-based access control (RBAC). New users do not have any permissions assigned by default. You need to first add them to one or more projects and then assign roles to these users. The users then can perform specified operations on cloud services based on the permissions they have been assigned.
CodeArts provides 11 system roles for R&D processes, such as IPD and DevOps. You can also create custom roles and assign them different permissions.
| Role | Description |
|---|---|
| Project administrator | A general owner of a project who manages all settings and members of the project, including creating, deleting, and modifying the project, assigning and canceling permissions of other roles. |
| Project manager | A primary owner of a project who manages requirements, plans, progress, and risks of the project, and coordinates work in the project team. |
| Product manager | Responsible for product design and planning, including defining product requirements, prototypes, and user stories, communicating and collaborating with developers and testers. |
| Test manager | Responsible for testing, including managing test plans, test cases, test execution, and bug tracking, guiding and supervising test personnel. |
| O&M manager | Responsible for project O&M, including project deployment, monitoring, and fault locating and rectification. |
| System engineer | Responsible for the system architecture and infrastructure of a project, including designing, setting up, and maintaining project resources such as servers, networks, and databases. |
| Committer | Reviews and merges code committed by developers. |
| Developer | Writes, commits, merges, and branches code, creates and runs pipeline and build tasks. |
| Tester | Executes test cases, reports bugs, and verifies fixes. |
| Participant | Participates in a project and creates work items. |
| Viewer | Views a project and cannot perform any operations in any services. |
Instance-Level Permissions
These permissions take effect for a specific repository or pipeline, for example, viewing, executing, editing, and deleting a pipeline.
Instance-level permissions are configured by the creator of the corresponding instance.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.
