Support the transfer of groups

Description

Support the transfer of groups

As in Issue #2772 stated there should be an option to move existing groups into other groups.

This would make reorganizing large groups to a group/subgroup structure much easier and avoids moving hundreds of projects manually.

Proposal

Allow groups and subgroups to be transferred around between other groups:

• Subgroups to groups
• Top-level groups to groups
• Top-level groups to subgroups

Links / references

#2772 (closed)

Documentation blurb

(Write the start of the documentation of this feature here, include:

1. Why should someone use it; what's the underlying problem.

Transfer of of group and all of it's project to another namespace

2. How does someone use this

From the groups settings choose the new target group where the current group should reside

During implementation, this can then be copied and used as a starter for the documentation.)

@Flipez I was wondering how long it would take for this proposal to come along 😆 Thanks for raising

Related issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/29718

added ~480950 feature proposal settings labels

I think that this proposal makes sense

changed title from Allow converting groups to subgroups to Support the transfer of groups

@Flipez I hope you don't mind. I made some edits to the description and edited it to adhere to our Feature Proposal template

@markglenfletcher Sure, no problem. I am happy about everything that brings us closer to a solution ;)

mentioned in issue #29944 (closed)

From the issue #29919 (moved) I created with webdev.comon:

Allow groups / subgroups to be transferred to other groups / subgroups. User case: Existing groups that were segmented by client.

Proposal

When editing groups / subgroups, you should be able to select a top level group minimum. For complex scenarios, ie, multiple nesting, add a advanced options link that turns the group path rename box into a textfield, where you can manually input the full path.

GitLab should check if the path is valid and if the user is owner of the parent group. Example:

group1 -> group2/subgroup1/subgroup2

Should verify that the user is a owner of subgroup1.

mentioned in issue #29718 (closed)

#19860 (moved)

mentioned in issue #30450 (closed)

When we first started using gitlab almost a year ago, subgroups was one of the only missing gitlab features. Our main issue was with accessibility (all restricted) and user management. Having to add every user to numerous groups or even projects (of which there are hundreds) was just not feasible, which is why we went with around 10 relevant groups, each containing many individual projects consisting of several repositories. Now that gitlab 9 brought solid support for inherting access, we'd like to adapt our existing organisational structure. (e.g. move group EngineeringStandards to EmbeddedDevTeam/Engineering Standards)

The general proposal looks fine for our use case, but my main concern is braking old links/code when moving projects. We've had this happen a lot in the beginning, when we were still experimenting with group and project names. Dead links would just result in a 404, without even a hint that the project might have been moved/renamed.

Which is why I think such a moving feature should have support for both or either:

a) "burning" old project paths, making them static paths to the moved project

b) redirecting to a semi-intelligent search page, that suggests a search string based on the project name

mentioned in issue #31885 (moved)

mentioned in issue #32710 (closed)

I also need this feature.

We're on the same boat as @MRentschler

We have about 20 groups now in local gitlab instance, each containing subsets of our developers.

We are now trying to integrate new gitlab features such as the issue boards, but it's very hard to keep track of 20 boards, or set up a milestone involves features from different groups.

We need either issues, milestones and boards shared among all our gitlab instance, or to move all our groups inside another new group. And manage it all from there.

Probably the second option is easier and makes more sense.

Also, having the option of not changing the git url of the repositories when transferring would be great, because we have around 500 repositories that we'd have to rename.

I need this.

We have almost 500 projects distributed across 34 groups. I just figured we could really benefit from having these 34 groups distributed among 3 root groups. Doing it by hand would be extremely tedious.

I would like to have this feature, too.

as this doesn't seem to be on any roadmap (no target version), could someone provide gitlab-rails commands to move projects from one group to another, or reparent existing group under another?

i have current structure:

• /infra/chef-repo
• /chef-cookbooks/

i want to have:

• /chef/chef-repo
• /chef/cookbooks/

it could be done easily as:

• create group /chef
• move repo /infra/chef-repo -> /chef/chef-repo
• move group /chef-cookbooks -> /chef/cookbooks

This makes a lot of sense since the addition of group-level secret variables. We'd like to use it to factor secret variables on multiple existing project sets

A customer asked for this at https://gitlab.zendesk.com/agent/tickets/82332

added customer label

Initially when there are no sub groups we have created multiple groups for the same team. As they where introduced and we want to organize groups structure. This feature would help us a lot... There are other ways but it this way would be ideal one...

Another request for this: https://gitlab.zendesk.com/agent/tickets/82571.

thanks @collen, this is what we need!

We need this feature too.

Would love to have this issue for our organization too.

moved to gitlab#8924

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue