Progress

Before 9.0

• Allow nested groups in URL (routing) of rails application !7459 (merged)
• Workhorse support gitlab-workhorse#74 (closed)
• Add nested groups on data level (db, migration, lookup etc). !7121 (merged),
• Inherit membership and permission from parent group - !8071 (merged)
• Update db, validations to allow creating groups with same path and different parent etc !7976 (closed), !8008 (merged), !8011 (merged)
• UI: General !8062 (merged), !8308 (merged)

9.0

• Allow create nested group in UI !8786 (merged)
• Documentation !9783 (merged)
• API support !9034 (merged)
• Nested groups GFM support !9184 (merged)
• Cache full_name and full_path !8979 (merged)
• Limit nesting level !9000 (merged)
• Search support for nested groups !8827 (merged)
• Show nested groups on dashboard, dropdown autocomplete etc !8827 (merged), !9227 (merged)
• Show parent groups on members page !9062 (merged)
• Project features like transfer, import should work for nested groups !9227 (merged)
• Project Members list should list all members of all ancestor groups #28786 (closed)
• It should not be possible to share a project with a group that's an ancestor of the group the project is in #28788 (closed)
• User doesn't have access to projects shared with a group if they're a member of one of that group's ancestors but not of the group itself directly #28787 (closed)
• GitLab.com HA compatible #28125 (comment 24973610)

After 9.0

• UX improvements: #25426 (closed), #30343 (closed) #31261 (closed)
• Cleanup: Update robots.txt #30795
• Cleanup: rename *_with_namespace with new methods #30786 (closed)
• Cleanup: groups GFM refactoring #30788
• Cleanup: Change project factory to use a nested group half of the time, so every feature is tested with projects under a user, under 1 groups, or under multiple groups? Downside: non-deterministic tests. #30790 (closed)
• Cleanup: Namespace#send_update_instructions, Namespace#any_project_has_container_registry_tags?, Namespace#shared_runners_enabled? should respect nested groups #30789
• Feature proposal: Transfer nested group feature #30547
• Feature proposal: GitLab pages support for projects inside nested groups #30548 (closed)
• Feature proposal: Notifications settings support for projects inside nested groups #30549
• Feature proposal: go import support #1337 (closed)
• Feature proposal: Group level labels don't work in subgroups / sub projects. This can be a choice to only implement later. #30551 (closed)
• Feature proposal: Child group should respect parent group share lock feature. #30550 (closed)

Info

Zendesk: https://gitlab.zendesk.com/agent/tickets/20180

• dev issue (not public): https://dev.gitlab.org/gitlab/gitlabhq/issues/2085
• feedback: http://feedback.gitlab.com/forums/176466-general/suggestions/3867903-allow-project-groups-to-be-organized-in-a-hierarch

Nested groups are requested by several (very) large customers and now also a number of potential customers. In addition, it's the highest requested feature on feedback.gitlab.com.

We need to consider this well. Feel free to edit this issue.

Reasons people want this:

1. separate internal / external organizations in GitLab instance (this is a concrete request from a customer)
2. organize large projects, making it potentially easier to separate permissions on parts of the source.
3. make it easier to manage people and control visibility

Implementation questions

1. Do we want this?
2. How deep can the nesting go?
3. How do we call it? Others call this "organisations", but that can be limited if we want to support further nesting
4. If it's just plain groups, do we expect the same integrations, settings, etc such as LDAP, Hooks
5. How can we represent this in a non-confusing way?
6. How can we maintain transparency of visibility of a project, users, etc?

Next steps

We can only do this once, well. Otherwise we'll introduce issues with paths, migrations, visibility and more. Moving to a nested model is easy, moving away from it is very painful.

I suggest we work out a detailed proposal here, followed by a mockup, then a design and only then it will be implemented. By doing this more formal than we usually do, it forces us to think more and repeatedly about every part of the implementation. I do think it's acceptable to do it iteratively, as we always do. For instance, first introducing only one level of hierarchy (gitlab-org / repos / gitlab-ce) to see how it works out, before (if we want this) adding more levels. Or restricting features depending on the hierarchy.

We should probably leave the current groups as the highest level.

Thoughts?

@dzaporozhets @sytses @DouweM @marin @jacobvosmaer @ayufan