## Problem GitLab uses an admin panel to configure many settings that cascade down to all projects/groups and to manage the instance ([link to docs](https://docs.gitlab.com/ee/administration/)). This is an effective and common pattern, but it has led to a few problems: * There's no way to apply settings to multiple top-level groups at once outside of the admin panel. Only system administrators have access to the admin panel and essentially get pseudo access to the entire instance. * Because of the elevated permissions that users with an admin role have, only select GitLab, Inc. employees are admins on the GitLab.com instance. This means that any settings built in the admin panel are not accessible to customers on GitLab.com. * The admin panel is the only place we can build settings that cascade down to multiple projects/top-level groups. * Building settings that are configurable in top level groups solves the problem for GitLab.com customers but self-managed customers now have to manage settings in multiple places. They also lose the ability to configure all groups/projects according to their best practices or regulatory mandates. ## Proposal [Figma iteration work file](https://www.figma.com/file/A2o0kllTnwk4Nf9QgnuXpc/300184-Bring-Admin-Users-screen-to-SaaS?node-id=0%3A1) To solve the problems above, we should: * [**Separate the settings in admin into two categories**](https://gitlab.com/gitlab-org/gitlab/-/issues/322413) * Hardware settings: related to running the GitLab instance * Settings that apply to groups and projects that should cascade down from a higher level * [**Implement an organization object**](https://gitlab.com/groups/gitlab-org/-/epics/9266) that contains all groups, subgroups and projects of an implementation * [**Build a way to apply settings to multiple groups at a time from a organization.**](https://gitlab.com/groups/gitlab-org/-/epics/9282) We can also present the option to disallow overriding settings in groups/subgroups/projects below it. * An instance administrator can define an organization setting and push to all groups/subgroups/projects. * A group maintainer+ can define a setting and push to all subgroups and projects. * Upon the creation of a new subgroup, it will use the settings of the immediate parent group, or the organization setting if it was defined as not being able to be overwritten * The organization or immediate parent group can toggle whether a setting can be overwritten by a subgroup/project or not * If overrides are not prevented, then group administrators can toggle the setting * **NOTE**: This model would be much easier to build once we have implemented the [recommendations from the simplifying groups and projects working group](https://gitlab.com/gitlab-org/gitlab/-/issues/254991). We are proposing consolidating groups and projects so having a single type of object to administer in this menu would make this much simpler. See https://www.figma.com/proto/Ef1mLF5FGZ6Jx7UsR3Unjk/Simplify-Groups-%26-Projects-Iteration-Plan?node-id=1%3A731&viewport=1396%2C697%2C1&scaling=min-zoom  | Current screen | | ------ | |  | ## Next Steps - [ ] [Develop a method to manage settings for multiple projects/groups at once and that is inherited to all groups/projects below: (Cascading settings)](https://gitlab.com/groups/gitlab-org/-/epics/9282). - [ ] [Build a "locking" mechanism to prevent overriding the value set at higher levels](https://gitlab.com/gitlab-org/gitlab/-/issues/324097) - [ ] [Inventory and separate Admin settings that are truly for the instance vs group settings that we push to all groups in an instance.](https://gitlab.com/gitlab-org/gitlab/-/issues/322413) - [ ] Move the Admin group settings into a different place in admin (or a new section in the existing admin menu) - [ ] Surface organization (group/project) settings in a new consolidated administration menu ## Related Epics and Issues * [Add Administration menu for Group Owners](https://gitlab.com/gitlab-org/gitlab/-/issues/209020) * [Organization to replace instance-level functionality with group-level features](https://gitlab.com/groups/gitlab-org/-/epics/4257) * [Migrate Groups and Projects To Namespaces](https://gitlab.com/groups/gitlab-org/-/epics/2885)