Allow Users to Use a GitLab License for Multiple, Top-Level Namespaces on SaaS
Proposal
Ideally, customers could always leverage Transfer a Group (also available via the API) to consolidate all of their groups into a single, top-level namespace.
Currently, users are not allowed to register multiple top-level namespaces on SaaS with a single license, although a self-managed licenses can be applied to multiple instances. This is valuable when:
- Allow selective SSO enforcement for Gitlab.com ... (#9630)
- Customers have more than one SAML provider (a namespace is only allowed one)
- Customers need to separate workloads amongst teams to restrict access (given that SaaS has no "internal projects" like Self-Managed) and the Minimal Access role is not always sufficient. The Minimal Access Role consumes an ultimate license seat (unlike the Guest User role)
- Customers have existing namespaces that they want to consolidate due to the Efficient Free Tier announcement, but cannot due to
- the inability to move projects with active container registries or
- they heavily rely upon CI Includes which won't be redirected.
- they rely on API calls and don't want to experience an outage of the API usage. Redirect GitLab API calls when necessary, after... (#30013)
- Epics are rolled up which is problematic when customers don't want people granted access in subgroups to be able to see top-level epics #358241. Furthermore, the 15.5 released ability to add issues to epics across top-level groups will make this even more attractive to keep separate.
- Due to access levels, it would be nice to allow a project in a separate namespace to inform DORA metrics on another namespace. For example, GitLab (the site) uses an incidents project for all outages on gitlab.com (which has its repository in gitlab-org). This merely means that the "time to restore" metrics are never consolidated.
I've provided a confidential issue that runs a scenario as to how much GitLab would have to pay if it could not use multiple, top-level namespaces.
This can also apply to Self-Managed if we were to, via Cloud Licensing, send back hashed (think unique values for each email address but cannot be reverse-engineered to determine the original email addresses) versions of all primary email addresses to identify all unique, active users. Then a single license could be applied to as many instances as desired and subsequently all user counts would be rolled up across instances.