Ability for organization members to create repositories but with reduced inherited permission #8356

New Issue

GiteaMirror · 2025-11-02T08:03:30-06:00

GiteaMirror commented

2025-11-02 08:03:30 -06:00

Originally created by @eeyrjmr on GitHub (Jan 14, 2022).

Feature Description

Presently, within TEAM setting of an organization there is the ability to grant team members the ability to create repositories within an organization. However, this grants them admin access to that repository and with that comes two rights which having some additional control over would be beneficial.

The ability to add collaborators. In the event that a user is a RESTRICTED user for some reason, having "random" users add them to an organization repository can cause some problems
The ability accept a PullRequest regardless of the the number of approvers that have been selected as part of branch protect.

Adding collaborators should be an organization consideration in as far as, if a member is not part of the organization, they can't be added to a repository. This might mean a staging TEAM (no read access) is required to permit users pick from a list of organization member's

Restricting an admin from merging a PULL REQUEST is to stop accidental bypass of a valid signoff step while still permitting users to have admin rights for other housekeeping activities. As admin of an org/repo they will inherit the right to go in and change the permissions of a repository to permit admin forcing merge, but this is now a conscious choice (maybe due to people AFK) rather than accidental

Screenshots

No response

Originally created by @eeyrjmr on GitHub (Jan 14, 2022). ### Feature Description Presently, within TEAM setting of an organization there is the ability to grant team members the ability to create repositories within an organization. However, this grants them admin access to that repository and with that comes two rights which having some additional control over would be beneficial. 1) The ability to add collaborators. In the event that a user is a RESTRICTED user for some reason, having "random" users add them to an organization repository can cause some problems 2) The ability accept a PullRequest regardless of the the number of approvers that have been selected as part of branch protect. Adding collaborators should be an organization consideration in as far as, if a member is not part of the organization, they can't be added to a repository. This might mean a staging TEAM (no read access) is required to permit users pick from a list of organization member's Restricting an admin from merging a PULL REQUEST is to stop accidental bypass of a valid signoff step while still permitting users to have admin rights for other housekeeping activities. As admin of an org/repo they will inherit the right to go in and change the permissions of a repository to permit admin forcing merge, but this is now a conscious choice (maybe due to people AFK) rather than accidental ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:03:30 -06:00

GiteaMirror referenced this issue

2025-11-02 09:28:51 -06:00

Updating OAuth2 Auth Sources in CLI requires manual intervention in WebUI or restart #11142

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8356