跳到主要内容

Roles and Permissions

System Roles and Permissions


Different users have different permissions, which depend on their roles and permissions within the organization or project. In public projects and organizations, all logged-in users will enjoy the following permissions:

  • Create new issues
  • Create pull requests (PRs) in the project
  • Post comments (including commenting on issues, PRs, commits, and discussions)
  • Clone or download the project code
  • View the project wiki pages
  • View organization or project discussions
  • View the organization's public boards

In addition to the permissions for public projects, there are some features that are not restricted by the permission system:

  1. The creation of lightweight PRs does not rely on code push permissions. When the project enables lightweight PRs, any platform login user can submit a lightweight PR.
  2. Protected branches and protected tags follow the enforced protection rules.

System Roles


In GitCode, system roles are divided into the following types:

  1. Administrator (Owner): An administrator of the organization with full permissions and final decision-making authority.
  2. Maintainer: A maintainer of the project or organization responsible for daily maintenance tasks such as handling issues and PRs.
  3. Developer: Writes and submits code, participates in development and discussions.
  4. Reporter: Reports issues, provides feedback, and participates in project discussions.
  5. Guest: Browses project permissions, participates in public discussion area discussions.

Organization Administrators

ResourcePermission
OrganizationDeleteSettingsUpdate
ProjectCreateForkUpdateDeleteSettingsArchiveTransfer
CodePushDownload
MembersInviteUpdateRemove
IssuesCreateUpdateClose/OpenPinLock
LabelsCreateUpdateDelete
MilestonesCreateUpdateDelete
BranchesCreateDelete
TagsCreateDelete
Pull RequestsCreateUpdateReviewApproveMergeCloseReopenTest
CommentsCreateResolve
DiscussionsCreateUpdateLockPinClose/Open
BoardsCreateUpdateDeleteClose/Open

The highest role for project members is the administrator, and administrator permissions can only be inherited through the organization; they do not support adding "administrator" permissions directly in the project.

  1. Creators can update the title and description of Issues and PRs and also close or reopen them.
  2. The author of a comment can edit and update the comment.
  3. The list of organization and project members can only be viewed by organization and project members.
  4. Label permissions include both organization labels and project labels.
  5. Security issues submitted by users can only be viewed by the issue author and project members.
  6. The permissions for the project wiki are the same as those for pushing code to the project.
  7. The permissions for project releases are the same as those for project tags.
  8. Resolving in a comment refers to resolving marked issues in PR code reviews.

Organization/Project Maintainers

ResourcePermission
OrganizationSettings
ProjectCreateForkSettings
CodePushDownload
MembersInviteUpdateRemove
IssuesCreateUpdateClose/OpenPinLock
LabelsCreateUpdateDelete
MilestonesCreateUpdateDelete
BranchesCreateDelete
TagsCreateDelete
Pull RequestsCreateUpdateReviewApproveMergeCloseReopenTest
CommentsCreateResolve
DiscussionsCreateUpdateLockPinClose/Open
BoardsCreateUpdateDeleteClose/Open
  1. The creator of an Issue or PR is allowed to update the title and description of the Issue or PR, and the creator can close or reopen the Issue or PR.
  2. The author of a comment is allowed to edit and update the comment information.
  3. The list of organization and project members can only be viewed by organization and project members.
  4. Label permissions include both organization labels and project labels.
  5. Security issues submitted by users can only be viewed by the issue author and project members.
  6. The permissions for the project wiki are consistent with the project code push permissions.
  7. The permissions for project releases are consistent with the project tag permissions.
  8. Resolving in a comment refers to resolving marked issues in PR code reviews.

Organization/Project Developers

ResourcePermission
ProjectCreateFork
CodePushDownload
IssuesCreateClose/Open
BranchesCreateDelete
TagsCreate
Pull RequestsCreateReviewMergeTestClose
CommentsCreateResolve
DiscussionsCreateUpdateClose/Open
BoardsCreateUpdateClose/Open
  1. The creator of an Issue or PR is allowed to update the title and description of the Issue or PR, and the creator can close or reopen the Issue or PR.
  2. The author of a comment is allowed to edit and update the comment information.
  3. The list of organization and project members can only be viewed by organization and project members.
  4. If "Prevent developers from creating tags" is selected, they will not be able to create tags.
  5. If "Prevent developers from creating branches" is selected, they will not be able to create branches.
  6. Security issues submitted by users can only be viewed by the issue author and project members.
  7. The permissions for the project wiki are consistent with the project code push permissions.
  8. The permissions for project releases are consistent with the project tag permissions.
  9. Resolving in a comment refers to resolving marked issues in PR code reviews.

Organization/Project Reporters

ResourcePermission
ProjectFork
CodeDownload
IssuesCreateClose/Open
Pull RequestsTest
CommentsCreateResolve
DiscussionsCreateClose/Open
  1. The author of a comment is allowed to edit and update the comment information.
  2. The list of organization and project members can only be viewed by organization and project members.
  3. Security issues submitted by users can only be viewed by the issue author and project members.
  4. Resolving in a comment refers to resolving marked issues in PR code reviews.

Organization/Project Guests

ResourcePermission
IssuesCreate
CommentsCreate
DiscussionsCreate
  1. The author of a comment is allowed to edit and update the comment information.
  2. The list of organization and project members can only be viewed by organization and project members.
  3. Security issues submitted by users can only be viewed by the issue author and project members.