[FEATURE] Allow changing team permissions per repository #6889

New Issue

GiteaMirror · 2025-11-02T07:10:04-06:00

GiteaMirror commented

2025-11-02 07:10:04 -06:00

Originally created by @Reinitialized on GitHub (Feb 17, 2021).

Currently, Gitea restricts the ability to change an entire teams permissions on specific repositories, requiring me to have default permissions set to be more permissive than I desire. It would be nice to be able to override the permissions of a team per repository, so one can have a team which is read-only, then grant write/administrator to desired repositories.

Originally created by @Reinitialized on GitHub (Feb 17, 2021). Currently, Gitea restricts the ability to change an entire teams permissions on specific repositories, requiring me to have default permissions set to be more permissive than I desire. It would be nice to be able to override the permissions of a team per repository, so one can have a team which is read-only, then grant write/administrator to desired repositories. ![Screenshot from 2021-02-17 17-17-14](https://user-images.githubusercontent.com/20674500/108280683-28228d80-7144-11eb-9e66-e9833295ce45.png)

GiteaMirror added the type/proposal label 2025-11-02 07:10:04 -06:00

GiteaMirror commented

2025-11-02 07:10:05 -06:00

@bestlinuxgamers commented on GitHub (May 26, 2021):

Yes, the team's permissions could simply serve as "default" permissions that can always be changed. Perhaps for teams in the Collaborator tab, a "Default" button/selector could then also be added that sets/resets the permissions back to the "default" permissions.

@bestlinuxgamers commented on GitHub (May 26, 2021): Yes, the team's permissions could simply serve as "default" permissions that can always be changed. Perhaps for teams in the Collaborator tab, a "Default" button/selector could then also be added that sets/resets the permissions back to the "default" permissions.

GiteaMirror commented

2025-11-02 07:10:05 -06:00

@Morriz commented on GitHub (Jun 21, 2022):

I assumed this would work exactly like GitHub. How on earth can one assume access permissions for a team instead of for the scope they are linked to?

Access permissions are about access, which implies knowing what to access. Blindly setting RBAC on a team without scope is pretty reckless and introduces bad practices like "most privilege" (as oppposed to "least privilege").

After learning this I am now very sad, as we have adopted Gitea and spent so much work on it. This is unacceptable and so we have to move to something more thought out like GitLab probably.

@Morriz commented on GitHub (Jun 21, 2022): I assumed this would work exactly like GitHub. How on earth can one assume access permissions for a team instead of for the scope they are linked to? Access permissions are about access, which implies knowing what to access. Blindly setting RBAC on a team without scope is pretty reckless and introduces bad practices like "most privilege" (as oppposed to "least privilege"). After learning this I am now very sad, as we have adopted Gitea and spent so much work on it. This is unacceptable and so we have to move to something more thought out like GitLab probably.

GiteaMirror commented

2025-11-02 07:10:05 -06:00

@Morriz commented on GitHub (Jun 21, 2022):

And then I realize that Gitea is probably the only free to use hosted git solution, and that there are no real alternatives ;(

@Morriz commented on GitHub (Jun 21, 2022): And then I realize that Gitea is probably the only free to use hosted git solution, and that there are no real alternatives ;(

GiteaMirror commented

2025-11-02 07:10:06 -06:00

@Reinitialized commented on GitHub (Jun 21, 2022):

After learning this I am now very sad, as we have adopted Gitea and spent so much work on it. This is unacceptable and so we have to move to something more thought out like GitLab probably.

GitLab is foss, just not the features you want to be free :)

Gitea is an awesome project, but like a lot of FOSS projects, they are volunteer-based. They will most certainly get to this at some point, just don't know when. I'd love to either contribute myself or put money where my mouth is for things like this, but I have no experience with Go nor the free income to do so right now. Best option is to either wait or hope someone else finds this just as important and supplies one of the other.

@Reinitialized commented on GitHub (Jun 21, 2022): > After learning this I am now very sad, as we have adopted Gitea and spent so much work on it. This is unacceptable and so we have to move to something more thought out like GitLab probably. GitLab is foss, just not the features you want to be free :) Gitea is an awesome project, but like a lot of FOSS projects, they are volunteer-based. They will most certainly get to this at some point, just don't know when. I'd love to either contribute myself or put money where my mouth is for things like this, but I have no experience with Go nor the free income to do so right now. Best option is to either wait or hope someone else finds this just as important and supplies one of the other.

GiteaMirror commented

2025-11-02 07:10:06 -06:00

@eeyrjmr commented on GitHub (Jun 21, 2022):

Presently what you describe is achievable but you require multiple teams to realise what you want.
Presently you assign repositories to teams but what would be required is assigning teams to repositories. This way per repo access can be managed based upon team needs

I am confident gitea will get there and improvements in team management (creation, management and ACL) are more than likely going to be needed once federation is deployed

@eeyrjmr commented on GitHub (Jun 21, 2022): Presently what you describe is achievable but you require multiple teams to realise what you want. Presently you assign repositories to teams but what would be required is assigning teams to repositories. This way per repo access can be managed based upon team needs I am confident gitea will get there and improvements in team management (creation, management and ACL) are more than likely going to be needed once federation is deployed

GiteaMirror commented

2025-11-02 07:10:06 -06:00

@Morriz commented on GitHub (Jun 21, 2022):

Approprating "teams" to achieve certain "roles" is of course a dirty hack and won't work for OIDC teams, which are under strict supervision of IAM admins.

@Morriz commented on GitHub (Jun 21, 2022): Approprating "teams" to achieve certain "roles" is of course a dirty hack and won't work for OIDC teams, which are under strict supervision of IAM admins.

GiteaMirror commented

2025-11-02 07:10:06 -06:00

@eric-j-ason commented on GitHub (Feb 20, 2024):

I'm I understanding this correctly that you first create a group and specify its permissions, but only later specify to what repositories these permissions apply?

It seems, then, that you can't have a group with read and write access to one repository, but read-only access to another repository? Is this so?

@eric-j-ason commented on GitHub (Feb 20, 2024): I'm I understanding this correctly that you first create a group and specify its permissions, but only later specify to what repositories these permissions apply? It seems, then, that you can't have a group with read and write access to one repository, but read-only access to another repository? Is this so?

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#6889