Allow group level restriction of visibility levels
Problem to solve
While we allow visibility restrictions for projects and snippets, we only allow this at the instance level. For large EE instances, however, it may be infeasible to completely restrict a visibility type across the instance.
Instead, it might be desirable to do this at the group level. For instance, it may be useful to set a confidential group with sensitive client information to restrict projects from being set to internal/public. Conversely, for a group set up for a hackathon, it may be useful to restrict private groups.
Proposal
- In the Settings for a Group, allow the group to restrict the use of private, internal, or public projects.
- This setting should honor any instance-level settings and not be able to override them.
- If restrictions are set in a parent group, subgroups should inherit these restrictions from the parent group.
- When creating a project in a group with a group-level visibility restriction, these options should not be available in the UI (greyed out with an appropriate message).
- The API should be similarly affected.
What does success look like, and how can we measure that?
- An Owner or admin should be able to restrict project visibility.
- At least one visibility setting should be required.
- The group shouldn't be able to override instance-level settings; only add additional restrictions on top of them.
- A user attempting to create a project via API or via the UI with restricted visibility settings should see an appropriate warning/error message.
Links / references
Edited by Jeremy Watson (ex-GitLab)