Gitea: Team Repository creation in Organisation

[meerkampdvv]

• Gitea version (or commit ref): 1.5.2
• Git version: 2.19.1
• Operating system: CentOS 7
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [x] Yes (provide example URL) https://try.gitea.io/sufo
  
  
  • [ ] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

Description

I created a Organisation "sufo" added a team "suo-team". The User "derme" is not owner of the Organization but Member of the Team.
The User derme is not able to create Repositories for the Organisation. The Team has Administrator rights for the Team Repositories.

Is this the Correct behavior ? in case a Team Member wants to create a new Repo he has to ask the Org Owner ?

[udeved]

We have a similar issue with repo creation for team member.

Our artix linux package repository setup:

• org B has tons of package repos associated to teams
• org A has super repos that pull with git subrepo the package repos from org B

As it is right now, only administrators can create a repository in org B?

Would be nice to have a more fine grained user privileges, so that in our case, team members of org B can create a repo without being administrator.

[altinnadmin]

@meerkampdvv @udeved
Just to make sure we're one the same page. Would functionality like this solve your needs?
Also, see the doc from GitHub.

@lunny Not sure how complex adding this functionality to Gitea would be? Our team is using Gitea as part of a new product we're building, but we have not yet looked at the Gitea-code or contributed any changes.

[meerkampdvv]

@altinnadmin
Seems correct. Non-Owners should be able to create Repos for the ORG.

[udeved]

@altinnadmin

Looks exactly like what we would need, maintainers(non-admin team members) of a given org can create repos from api, granted they have privs to do so.

[lunny]

How about add an option on team settings which allow team members to create repositories or transfer repositories to the organization?

[igor9292]

can transfer to 1.8.0 or 1.9.0?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[coolyrat]

any plan for release? This is what my company wants too.

[lunny]

No people are working on this.

[davidsvantesson]

There are related access issues that need to be considered if this feature are introduced.

If a user belongs to a team that has "Create repo access" and creates a repo, only the owner would have admin (or indeed any) access to the repo. So the repo creator shall probably be automatically added as repo admin when creating the repo (no problem). Then if the creator want's someone else to access the repo he/she need to add them as collaborator. But probably he rather would like to give access to a whole team (the team with create repo access or some other team). However adding repositories to teams is also currently limited to the organization owner.

So for "create repo access" to be truly useful, I think one or both of the following features would be needed as well:

• Allowing repo admin to add teams as collaborators (To not be confusing, this should be same as Team Repository, but seen from Repo Collaboration settings)
• Organization-wide access modes (None, Read, Write, Admin) that give a team that access to all repositories in the organization.

[guillep2k]

If I understand the problem properly, perhaps the create repository page should work like this:

1. Is it a user repository? Work like usual.
2. Is it an org repository, and the user is org admin? Work like usual.
3. Is it an org repository, and the user can create because he or she belongs to teams can create blue and can create yellow? The page should make the user choose a team to add this repository to (only those two teams will show up).
4. Case (3) can skip the team selection if there is only one possible choice.

For example, "My Org", for which user Martin is the admin, has four teams:

• "Developers", with commit permissions for users Mike, John, Lynda, Bob.
• "Reviewers", with create issue permissions for users Rick, Pablo.
• "Project Managers", with create repository permissions for users "John" and "Bob".
• "Special Admins", with create repository permissions for user "Bob".

As we can see, Bob belongs to teams "Developers", "Project Managers" and "Special Admins". But he is not the org admin. When Bob wants to create a repo, he must choose to which team he wants to add the repo to; valid options are "Project Managers" and "Special Admins".

However, if John wants to create a repo, Gitea will automatically add it to "Project Managers" because that's the only team giving John the ability to create a repo for that organization.

The explanation is very complex, but implementation should be simple.

[lafriks]

This should have special right (unit) for this than

[davidsvantesson]

@guillep2k I don't think access rights settings should be added to the repo creation page, it should not be too complex.

If Bob adds a repo "New Cool Software", he probably wants "Developers" to be able to start work on it (because project managers are not going to do that). He might not even be member of developers himself. Thus he still need to go to the organization admin (owner) to do that.

I think being able to create a repository should imply you shall have full access to that repo (i.e. repo admin), otherwise it would be limited to only owners having full access to the new repo. In your case (3), I therefore think the creator automatically shall become repo admin.

For Bob to be able to start assigning Developers to work on the software, it should be possible to add Teams as collaborators (same as Team Repos but seen from repo settings page). Drawback for that is that Bob as repo admin will be able to see all teams in the organization. I am not sure if there can be any reason to keep team names secret for those that doesn't belong to them, I don't see any purpose of that (you can anyhow see all members of the organization you belong to)

[guillep2k]

I don't think access rights settings should be added to the repo creation page, it should not be too complex.
I think being able to create a repository should imply you shall have full access to that repo (i.e. repo admin)

@davidsvantesson Currently there's no way to add the repository to a team unless you are the team manager; i.e. the org admin.

For Bob to be able to start assigning Developers to work on the software, it should be possible to add Teams as collaborators (same as Team Repos but seen from repo settings page).

Fair enough, this will solve that. However, I don't much like the fact that you must know the team names in advance to do this; I'd rather have a list in the case of teams (it shouldn't be too long). And there's the potential problem of name clashing. Can a user and a team be both named bob?

Drawback for that is that Bob as repo admin will be able to see all teams in the organization. I am not sure if there can be any reason to keep team names secret for those that doesn't belong to them, I don't see any purpose of that (you can anyhow see all members of the organization you belong to)

I agree, at least if team members are kept private. But changing the current behavior would be a breaking change. I see value on @lafriks suggestion, here:

This should have special right (unit) for this than

So granting this unit to a user should also come with the ability of seeing all the teams in the organization. The org admin will be advised about it in the permission description.

If the user creating the repo automatically gains admin rights over it, the org admin must have nonetheless the ability to revoke those admin rights from that user at any time.

[davidsvantesson]

So granting this unit to a user should also come with the ability of seeing all the teams in the organization.

Not seeing teams you don't belong to can be seen as a convenience or a security/integrity issue. It is actually possible to list all teams in an organization you are member of in the API (but not the members).

I created #8045 as a concrete suggestion on adding team access.

[guillep2k]

So granting this unit to a user should also come with the ability of seeing all the teams in the organization.

Not seeing teams you don't belong to can be seen as a convenience or a security/integrity issue. It is actually possible to list all teams in an organization you are member of in the API (but not the members).

I created #8045 as a concrete suggestion on adding team access.

I meant listing the team names, not their members.

[guillep2k]

So could this be closed as per #8045 ?

[davidsvantesson]

So could this be closed as per #8045 ?

Unfortunately no. That PR makes it possible to add teams from the repository settings, which in my opinion is necessary to make a fix of this issue really useful. After getting that done, I plan to submit another PR to also add a team setting to allow creation of organization repository. I think that is what is requested in this issue.

[davidsvantesson]

I didn't use the correct keyword in the PR, but I think this issue is included in Gitea 1.11 and thus can be closed.

[6543]

@techknowlogick can you change the milestone