Allow group owners to disable projects forking outside of GMA-group
A modification to this feature was made apart from GMA and released in 13.3
Problem
Top-level groups using SAML SSO can enforce the use of group managed accounts (GMA) to require users to create unique users that are tied to that specific group. These user accounts are used when SSOing into the group, and are tied to the email address received from the configured identity provider.
Group managed accounts were intended as a solution for enterprises on GitLab.com looking for more control over user activity. One gap for these enterprises is the use of personal projects; a personal project could be forked or cloned in a personal namespace, outside of the control of a group's owner, and accidentally expose valuable code.
Some organizations prefer to have the group be the only place that a user's able to interact with projects associated with the enterprise. By keeping them in the group, they're able to assert control over them and audit activity.
Proposal
For organizations using group managed accounts, a group Owner should be able to toggle whether or not group managed accounts are able to create forks outside of the group.
- When enabled, creating a fork should only be allowed if the fork is created inside the group associated with the group managed account.
- When disabled, a group managed account should be able to fork anywhere.
This option should be enabled by default when enabling group managed accounts (changing behavior of existing groups is not desired).
Note that this restriction would only apply to attempts to create new forks and won't affect any existing forks that are already in personal namespaces, which we should make clear in the documentation.