[FEATURE] Allow changing team permissions per repository

[Reinitialized]

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.

[bestlinuxgamers]

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.

[Morriz]

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]

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

[Reinitialized]

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.

[eeyrjmr]

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

[Morriz]

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.

[eric-j-ason]

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?