Standardize settings inheritance
This work is part of https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/11
Problem
Settings set at the admin or group level are sometimes shown at the project level. Sometimes the two settings have no bearing on each other. Sometimes settings set at the group level cascade to projects in the group. Sometimes cascading settings are able to be overridden, sometimes they are shown in a locked state.
- We are visually inconsistent in the way we signal cascading settings
- When setting something at a parent level, it's not always clear how it will or will not impact children
Goal
Standardize logic and visual treatment of setting inheritance, and document in Pajamas.
Use cases
Case | Example |
---|---|
Setting exists at Group and Project level, but have no relationship | Deploy tokens |
Setting set at Group level and shown at Project level, but not able to be overridden | Default branch |
Setting set at Group level with option at group level with option to allow overrides | Shared runners |
Setting set at Group level but can be overridden at project level | Integrations |
A group of settings set at the Group level, but can be overridden at the Project level | Jira integration |
Setting set at the project level and shown at the merge request level, but not able to be overridden | Squashing commits |
Setting selected at a parent level, can not be overridden by a child object | Merge request approval settings |
Setting set a group level can be overridden at a subgroup level if permitted | Delayed project deletion |
Audit: how is inheritance communicated?
Parent | Child |
---|---|
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
![]() |
![]() |
![]() |
|
![]() |
![]() |
Project settings (General > Merge requests):![]() |
MR form:![]() MR merge widget: ![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
nothing |
![]() |
![]() |
![]() |
|
![]() |
nothing |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
⬇
Design proposals based on audit - I am not familiar with these features so I've probably gotten things wrong
- These designs are rough to get the conversation started
- Everything is up for debate
Edited by Katie Macoy