Subgroups in Gitea

[ulm0]

Feature proposal

GitLab 9.0 now allows to create subgroups for groups/organizations, It would be great if we could do the same in Gitea.

• Subgroups Docs: https://docs.gitlab.com/ce/user/group/subgroups/

[gayprogrammer]

Does Teams provide some or all of this functionality? What is missing from Teams?

[bkcsoft]

Teams would not provide "endless" nested groups 🙁

In any case, this would require a large rewrite of how we're handling Organizations today (GitLab put a lot of time into Subgroups...) and would not be backwards compatible (hence why Subgroups in GitLab was introduced in a Major release so breaking changes was allowed 🙂 )

[bkcsoft]

And to better answer @razzintown, Teams can't have repositories.

[gayprogrammer]

Let me know if my understanding is correct:

Teams can't have repositories.

• Repositories may be assigned to one or more teams.
• Repositories may be set to private to prevent other teams from seeing them.

Teams would not provide "endless" nested groups 🙁

• Team names may contain a dash to give the appearance of nested groups, i.e. "company-department", "company-department-managers", etc.

Since multiple teams may share a private repo, is there any other functionality missing?

[bkcsoft]

Sub-groups are not only about permissions, but structure as well. Say you have an Orga with a total of 300 repos over 30 teams, there's no way to structure that w/o proper "folders" (sub-groups).

So in the end you end up with orga/team30/repo10 instead of orga/repo300

[bkcsoft]

In any case, this would break a lot of existing stuff and be a major overhaul so I'm setting this for 2.0 for now

[ghost]

This would automatically give us the pastebin/gist feature #693 as well, or any related idea, since some nested names could be reserved for those features like giteaUser/gist or giteaUser/pastebin just off the top of my head, or with a dot prefix if that's legal with git, not sure. It would also allow users to create new repos progamatically with permissions already set by the parent 'space'.

It could also eventually allow federation since it basically boils down to automagic merging, and using mirrors nested in reserved namespace would allow for manual conflict resolution as fallback without polluting the root namespace with lots of mirrors.

[tomdavidson]

We org our git projects into groups of bounded contexts. Where the git repo is, informs the purpose, scope, and communication channels, as well as the authorization to the project. subgorups can be valuable.

[Th3Whit3Wolf]

Is there any estimable timeline when this could potentially be implemented? This would be super useful.

[lunny]

@Th3Whit3Wolf No people are working on this.

[lakostin]

Still no update?

[6543]

dont see any

[Nicolab]

I use Gitea for myself and Gitlab for team work. In Gitlab we have subgroups containing a lot of repos. That's what's keeping us from migrating. This possibility in Gitea would be really great.
Is this feature is planned?

[lafriks]

It is planed but nobody does work on this currently

[Nicolab]

Ok thanks for the confirmation

[cwchristerw]

Currently this feature is already available in Github

[Asherslab]

would also love this feature. Our team is migrating from GitLab and this is a feature we sorely miss

[lafriks]

I'm planing to work on virtual subgroup functionality that would not affect urls so repository names would still need to be unique but it would allow grouping repos in subgroups

[tomdavidson]

I dig how GitLab groups can be used for access control - would the virtual subgroups be similarly used? ... and I like the namespace. For example, I'd like parent Gitea groups for bounded contexts. Each context could have subgroups based on convention as schemata or api or handbook, etc. Having to have unique names would end up with virtual-groupname/groupname-schemata or the like.

GitLab has some troubles sorting out GitLab Pages' domains with subgroups. What makes subgroups difficult with Gitea?

[bjeanes]

I agree, but I think virtual subgroups without namespaced paths is a good and easy starting point. I support that for sure but would also like to see it go further.

[Nicolab]

With or without URL path, the important thing is to have some repositories into subgroups.

[wxiaoguang]

I could understand many users really like this feature and I also like it, however, by my understanding, it is nearly impossible to implement it at the moment. There are too many blockers for it.

[atommaki]

.... it is nearly impossible to implement it at the moment. There are too many blockers for it.

So the work could start by making a list of these blocking issues.

[ghost]

8 years it has been. Can we setup a bounty for that feature ?
(also making this alone doesn't seems possible, it has to be a team work)

[lunny]

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

[VAllens]

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

When we implement the concept and design of groups,
why not be able to support multiple tiers easily?

But anyway, it's a very good start!

[lunny]

Yes, in the future, we plan to support structures like org1/-/group1/subgroup1/repo1. However, initially, we may limit support to a single tier to make it easier to be implemented.

[delvh]

Edgecases

Note, however, that before we implement anything like that, we must first think about the permission system.
This can only work if we define the permission system correctly.
There are quite a few edge cases I can think of at the top of my head:
How do we model teams then?
Is a team a unit across the entire organization?
Is a team only available for a specific subgroup?
Do we throw out teams entirely and model them as subgroups instead?
If the team is a cross-organizational unit, how are conflicting permissions handled?
I.e. user alice is part of group group and team team.
group is not permitted access to repo x. team however is. Is alice now able to see x, or no?
If we don't throw out the definition of a team with this, then what's even the difference between a subgroup and a team? Both should be able to do pretty much the same except the team is much more flexible in its permission system.

Is this worth it?

It's exactly these questions that make me ask myself if this feature is really worth it?
As far as I can see, a much simpler solution is to just use the term organization much more loosely (to compare it to bitbucket, simply use it as a project, so a set of connected repos that perhaps have a small "user filter" so that it is only accessible to some people).

Suggestion

I think at the heart of this discussion, there is a conflict between what is stated here and what is actually needed:
The proposed problem is to make orgs even more hierarchical.
I disagree with that approach: That makes a lot of problems for marginal gains.

What I think is needed instead is the following:
We need to improve the UI to allow much easier copying of the hierarchical structure:
For example, if it was possible to copy the hierarchy of one organization recursively (i.e. the new org receives the same users and teams as the old org) without copying the repos, this feature won't be needed anymore:
All of a sudden, you can achieve the same thing as with subgroups which are an exorbitant amount of work with a single button click to generate a new organization from an existing one.

Or am I missing something here?
Is there any usecase that isn't possible with an easy copy hierarchy UI that is possible with a we are 20 hierarchical layers deeply nested approach?

This UI would need to do two things:

1. Allowing to generate a new organization from an existing one (required)
2. one- or two way sync between organization/team members. (optional, couldn't that be achieved using LDAP filters or something like that that determine group membership?)

[bkilinc]

I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc.

[lunny]

Maybe we can support a custom filter on the repositories list, this approach will not touch any other infrastructure. The team can add repositories or a repository filter(we can have a new name for that). And also a default filter can be assigned to a team or a user in this organization. But I don't know whether this satisfy most of your requirements.

[VAllens]

I am just a user here. All I need is namespaces to repositories. I don't like gitlab's approach. it is confusing. Repositories are in organizational entities like groups. Namespaces are ok for me they are just prefixes. It can be shown as a tree. Groups are organizational structures. It can be handled elsewhere. One can give namespace permissions to groups etc.

For individual users, there is no team, no organization, so the existing functionality is perfectly adequate.
For enterprises, there are organizations, departments, teams with cross-departmental collaboration, and projects with cross-departmental collaboration, so the existing functionality is not sufficient.

[KarenArzumanyan]

Would you accept a router like org1/-/group1/repo1. Only one level group, no multiple groups supported.

Several levels of grouping are not often encountered in practice.
One level seems sufficient for 90% of cases.
At least one level is very necessary.
For example, there is a large project and several subprojects.
It is convenient to set up access to the group at once (this is very important).
It is convenient not to mix it visually with other projects.

A very good start with one level, maybe even sufficient.

[KlavsKlavsen]

one note on that notation though.. if repos belong to groups - and thats the same as "permissions" ? - then we agree repos that needs to be accessed by other groups - needs to be outside any group, or?
IMHO the team perms currently there is "not too bad" (although confusing that you can't decide per repo you add them to - what that teams perms are there)
So whats IMHO needed is only the visual grouping.. not access groups.. so I'd not call it groups if its ONLY for "visual filtering".. then it should merely be called category - as its not about permissions ?

[bkilinc]

For individual users, there is no team, no organization, so the existing functionality is perfectly adequate.

No, existing functionality is not adequate, if I have 200 repositories for example. I need to organize them in sub projects. There is no groups at this time, but there may be. so I should be able to give permissions to groups.

[mrexodia]

I know for a fact there are at least two companies that are not migrating from Gitlab to Gitea because there are no groups for organizational purposes. Groups are purely used to organize your organization's (aka development team's) repositories and one level is more than enough. This is already useful, purely so you do not have 200 repositories in a single list.

Making things like permissions/issue lists/whatever a prerequisite is just scope creep and will only add more and more delays to this feature which people have been requesting for almost 8 years(!) Once the basics are implemented you can always completely redo the feature with overengineered permission systems and other bells and whistles and spend another 8 years on that if necessary, but I think getting something out quickly will make 🤷🏻‍♂️

[Frankkkkk]

I totally agree. Same here. We wanted to migrate and "just" needed a simple hierarchy : /project-A/component1/code_a , and having 2 level "groups" would have been nice too. Of course there were other issues (the most important one was CI token rights to push on registries), but groups were one of them

[KlavsKlavsen]

If I wasn't clear - yes. Merely a categization of repos (1 level is fine) - so you can work with a "subset of repos" in a list - would be more than enough.
If that "category" - corresponds to what a team manages of repos - then one an just add those repos to the teams list of repos.. its not a big problem - so the simple solution helps a LOT - and then build on that.
the category could also match a project - or departments with multiple teams or whatever.. just having category (and cefault listing showing category name - not all repos below it) would be a very useful improvement.

[algora-pbc]

💎 $80 bounty • Frank Villaro-Dixon

💎 $100 bounty • jozek.woloch

Steps to solve:

1. Start working: Comment /attempt #1872 with your implementation plan
2. Submit work: Create a pull request including /claim #1872 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to go-gitea/gitea!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @GamerGirlandCo	Dec 25, 2024, 1:20:08 AM	WIP

[GamerGirlandCo]

/attempt #1872

• as with gitlab, this will be limited to 20 levels of nesting, which should be more than enough for most use cases
• gitlab has the ability to create secrets and runners isolated to a specific group, so whatever model the secret table uses will have to be updated. same applies to runners
• subgroups should be able to be mentioned; need to update the incoming message handlers to account for that

Options

• Cancel my attempt

[lunny]

Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request.

[GamerGirlandCo]

Hi @GamerGirlandCo , since this is a very complicated feature. Please discuss more in this issue before you can send a pull request.

@lunny here's a checklist i made over the last few days encompassing tasks that need to be completed

• backend
  • models
    • existing (to update)
      mostly, this entails adding a GroupID field to the following structs, and updating their accompanying Find...Options types to enable searching by group id
      • repository
      • action runner
      • action variable
      • action secret
    • new (to add)
      • group
      • group-team relation
        stores a team’s access level to a group
      • group unit
        like a repository unit, but grants or denies access to a specific unit at the group level. will override unit permissions defined on a team
  • API
    access to these endpoints is governed by read:organization and write:organization scopes
    • POST /org/{org}/groups/new → create a new group at the root level of an org
    • /org/{org}/groups/{group_id}
      • GET → retrieves the group
      • PATCH → updates the group's name and/or description
    • POST /org/{org}/groups/{group_id}/new → creates a new subgroup inside a group
    • POST /org/{org}/groups/{group_id}/move → moves a group to different group in the same organization, or to the root level if newParent is null or 0
    • POST /{username}/{reponame}/groups/move → moves a repository to a different group within an organization, or to the root level if newParent is null or 0
  • misc updates (high-level, non-exhaustive)
    • update GetUserRepoPermission function to take into account group permissions
    • update GetTeamRepositories to take into account group permissions
    • update condition builder functions in models/repo/repo_list.go to check for group access
• frontend
  • templates
    • create a sidebar containing a tree of links to organization groups and repos accessible to the currently logged-in user. this list should ideally be reorderable
  • pages
    • /{org}/groups/{group_id} → group home
    • /org/{org}/groups/{group_id}/teams → list of teams which have explicit access to the group. explicit access to the group may be granted via this page to teams that don't already have it
      • /org/{org}/groups/{group_id}/teams/edit → a page to edit a team’s permissions in a group. should require actor to have admin or owner privileges
    • /org/{org}/groups/{group_id}/settings → a settings page with the following
      • group-specific action configuration (variables, secrets, runners)
      • ‘display’ settings, such as
        • group icon
        • name
        • description

[Frankkkkk]

Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers

[GamerGirlandCo]

Does this allow for recursive groups ? If so, by seeing the URLs, I guess they don't show on the URL ? Cheers

yes it does, up to 20 levels :)

and on group pages, there will be a breadcrumb showing the group's ancestors

[wxiaoguang]

Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render)

And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better.

[GamerGirlandCo]

Thank you very much for your work! IIRC there is another blocker: how to generate and parse/handle the repo link correctly, because the "/{owner}/{repo}" format has been hard-coded everywhere for years, new design needs to handle the new path format correctly, otherwise many things won't work (for example: repo access, the markdown render)

my implementation doesn't modify the existing URL format.

And since this task is quite challenge and the participants should be very familiar with Gitea's internals, I think if new participants could start with some easy tasks (like improving tests, refactor legacy problems), then it would help to understand more details of internals and design the new approach better.

i guess that's fair. though i'd like to think that working on this for the past week (give or take) is teaching me about gitea's internals quite well :)