Project Members and Roles
A project is the lowest level in the member permission system and also the level with the most diverse member sources — members can come from projects, organizations, and enterprises.
I. Project Members
Member List
Go to Project Settings → "Project Members" to view all members of the project. The member list is displayed in three Tabs according to the source:
| Tab | Member Source | Management Permissions |
|---|---|---|
| Project Members | Members directly invited to the project | Can change role, can remove from project |
| Organization Members | Members who inherit access permissions through their organization | Can only view, cannot perform actions |
| Enterprise Members | Members who inherit access permissions through their enterprise | Can only view, cannot perform actions |
At the top of the Organization Members and Enterprise Members Tabs, there will be a prompt indicating the source organization/company name for these members, as well as a note that their permissions are determined by upper-level roles and cannot be directly modified by project administrators.
Invite Members
Project administrators and maintainers can invite new members in the "Project Members" Tab using the following methods:
Method One: Invite by Username/Email Click "Invite Member", enter the username or email of the invited user, select the role, and send the invitation.
Method Two: Invite Link Click "Invite Link", set the default role and validity period, then generate the invitation link.
Change Member Role
In the "Project Members" Tab, click on the member's role name to expand the dropdown menu and select the new role to modify it.
Note: Members in the "Organization Members" and "Enterprise Members" Tabs do not support changing roles.
Remove Member
In the "Project Members" Tab, select the corresponding user and click "Remove" to remove the member from the project.
II. Project Roles
System Roles
There are 5 system roles in a project, arranged from highest to lowest authority:
| Role | Description |
|---|---|
| Administrator | The project manager, with full permissions |
| Maintainer | The daily maintainer of the project, responsible for merging requests, releases, etc. |
| Developer | Writes and submits code, participates in development and discussions |
| Participant | Reports issues, provides feedback, participates in project discussions |
| Viewer | Has viewing permissions for the project, participates in public discussions |
Custom Roles
The project level cannot create custom roles, but custom roles created at the upper level (enterprise/organization) will automatically appear in the project's role list once permission inheritance is enabled — even if no members in this project are currently assigned this role.
Projects can locally override the permission matrix of these inherited custom roles, and the overridden permissions will only take effect within this project.
III. Role Priority Rules
When a member appears in multiple levels, the final effective permissions are calculated according to the following rules:
Proximity First
Project Role (current level) > Organization Role (inherited) > Enterprise Role (inherited)
If a member has been assigned a role specifically within the project, that role takes precedence, overriding the inherited role permissions from higher levels. This means that the project role can both increase and decrease the actual permissions of the member in the project — completely depending on the role assigned by the project.
Administrator Exception
The Administrator role of an organization and enterprise is not subject to the proximity-first rule. Even if assigned other roles at lower levels, administrator permissions always take effect.
Permission Calculation for the Same Person Across Multiple Levels
If Zhang San appears in the tabs of project members, organization members, and enterprise members, the final effective permissions are based on his role permissions in the project (i.e., the latest level assignment).
Next Reading: Custom Role Configuration