Skip to content

Sub groups

Progress

Before 9.0

9.0

After 9.0

Info

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

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