Organizations

Problem to solve

Gitlab offers two deployment models:

  • Self-hosted - Users have full access to all instance and group configuration options.
  • Gitlab.com - Users work within a single Group and only have access to Group configuration.

This model:

  • Limits the configuration options for group administrators on Gitlab.com. Some settings are only available at the instance level.
  • Forces Gitlab product teams to create multiple versions of similar settings for both deployment models to take advantage of them.
  • Doesn't offer group administrators a way to apply ALL settings to ALL their groups.
  • Limits for group configuration options on Gitlab.com since there's a single group to work within. Subgroups offer some flexibility but members and some settings are always inherited down from the top level group. Breaking the current inheritance model has proven to be challenging (#33534 (closed))

Intended users

User experience goal

Proposal

Create an object called an Organization that can provide an additional abstraction layer between an instance and groups. An instance would have a single Organization and GitLab.com would have one for each customer. We can transition top level group and instance level settings to an Organization.

This approach will enable us to:

  • Develop settings that apply to multiple groups/projects and build them once for Gitlab.com and self-managed.
  • Clean up logic built into top-level groups that make the user experience confusing.
  • Provide a clean delineation to represent unique customers in Gitlab.com. We currently rely on top-level groups.
  • Contain multiple top-level groups that are independent of each other and grant membership to each independently (“least privileged” access).
  • Allow interactions across top-level groups (#11402 (closed) , #205155 (closed) ) in a user defined collection of groups.
  • Is directionally aligned to the recommendations from the simplify groups and projects working group.
  • Makes it possible to pursue sharding in the future for a higher degree of isolation.

Why not use groups to meet these goals?

  • An end goal for security-minded organizations is to have completely independent groups but still have a way to define an organizational boundary around them. When you use a single group hierarchy you are not able to accomplish this. Groups have settings/members inheritance built into its core. Changing our inheritance model has proven challenging.
  • Enterprises want a way to have certain settings only be available to administrators and have those settings apply to their entire enterprise. This is one of the reasons why some settings are built at the instance level and not the group level. We already have certain settings that are available for a top-level group only. If we used top-level groups to mean organizations would need to continue to make top-level group-specific logic and over time this will increase the complexity of groups. See &4257 (comment 401388625) for some examples.

What's the MVC?

  • TBD

Further details

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-organizations https://confluence.atlassian.com/cloud/atlassian-organizations-964957873.html

Edited by Melissa Ushakov