跳到主要内容

Overview of the Member Permission System

Three-Tier Structure​

The member permission system of AtomGit consists of three levels, from top to bottom:

Enterprise ──→ Organization ──→ Project

Each level has its own members and roles, with upper-level members able to descend to lower levels, and lower levels able to directly invite independent members.

Core Concepts​

Where Do Members Come From​

The member list of each level is displayed in Tabs by source:

LevelMember Source TabDescription
EnterpriseEnterprise MembersMembers who have joined the enterprise directly
OrganizationOrganization Members / Enterprise MembersMembers who have joined the organization directly + members who have descended from the enterprise
ProjectProject Members / Organization Members / Enterprise MembersMembers who have joined the project directly + members who have descended from the organization + members who have descended from the enterprise

Member Flow Rules​

  • Upper Levels Can Descend: Upper-level members automatically gain access to lower-level resources, provided that their role has the "permission descent" attribute enabled
  • Lower Levels Can Invite: Lower-level managers can directly invite members to join this level, without being restricted by upper levels
  • Inherited Members Can Only View: Members obtained through descent can only be viewed in the lower-level list, not edited or removed

Role System​

System Roles​

Each level has fixed system roles, ordered by authority from high to low:

EnterpriseOrganizationProject
AdministratorAdministratorAdministrator
MaintainerMaintainerMaintainer
DeveloperDeveloperDeveloper
ParticipantParticipantParticipant
ViewerViewerViewer

Custom Roles​

  • Enterprises and organizations can create custom roles, with permissions configured as needed
  • The project level cannot create custom roles, but custom roles from upper levels will appear in the project role list. Projects can locally override their permission matrix
  • The name of a custom role cannot be the same as a system role

Core Rules​

Principle of Proximity​

When a member exists in multiple levels, the effective permissions are determined by the nearest level:

Project Role > Organization Role > Enterprise Role

If a role is assigned separately in the project, the project role's permissions take effect; otherwise, it traces upward sequentially.

Administrator Exception​

The Administrator role of an organization or enterprise is not subject to the proximity principle — even if other roles are assigned to it at lower levels, the administrator permissions always take effect.

Roles Determine Descent Scope​

When configuring roles at the enterprise or organization level, in addition to setting permissions for the current level, you can also set permissions for lower levels. When a role has the "permission descent" attribute enabled, the members of that role will automatically appear in the lower-level list with their configured lower-level permissions.

Quick Overview of Applicable Scenarios​

ScenarioRecommended Approach
The project needs all organization members to have accessEnable project permission descent on the organization role
The project needs to introduce external collaboratorsInvite members directly at the project level
Enterprise members need to adjust permissions (upgrade or downgrade) in the projectManage the member's role separately in the project to override inherited permissions
Need fine-grained control over permissionsCreate custom roles at the organization or enterprise level

Next, please read in the following order: