<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=218781) </details> <!--IssueSummary end--> ### Problem to solve As a team, we have many groups. I, as Team Leader, set default branch protection on main group to "Partially protected", and I want it to apply to every subgroup I create, because every our group has almost same settings. We want our devs to be able to push in projects they create and we don't want to set settings for every sub group. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### User experience goal The user should be able to apply Default branch protection to every subgroup. I see different ways how it can look like: - Setting automatically applies to every subgroup, but if subgroup Default branch protection setting has changed, parent group change will not override this setting. Changing subgroup setting should throw a warning - If checkbox on parent group has been set, children groups settings is locked ### Proposal I'm not an UX designer, but I have tried to describe how I see it in files, attached below  *Parent - locked*  *Parent - unlocked*  *Children - locked*  *Children - unlocked* ### Further details * Every subgroup should have setting inherit parent settings * It's logic to give management tools to parent group as they are usually created for teams or big projects with same settings needed for every children ### Permissions and Security Changing this setting requires same permissions as editing Default branch protection setting. This affects groups and every group inside it. ### Documentation * Default branch protection settings applies to all subgroups, where this setting has not changed, by default * If subgroup changes this setting, changing it in parent group should not affect it's value * Maintainers should have ability to change this behavior and apply parent setting to all childrens * If Maintainer applies strict setting, Default branch protection setting displays as locked in all it's childrens ### Availability & Testing I don't really yet see how it can affect user's experience. This setting is just about setting default value. Users still can change value in children groups. The only thing I see is existing groups. So, there should be info message with explanation ### What does success look like, and how can we measure that? * User can apply behavior, close to described in Documentation setting above ### What is the type of buyer? Dakota will not have to spend time on applying setting she wants to every subgroup she creates. She will stop worry about default branch protection and will not receive questions from Developers about they can't push in created branch. Skyler will also be sure he can, for example, disallow to push in default branch. --- As Default Branch Protection being available on Core (Free) as I remember, this should apply new setting for this enterprise group as well ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### Links / references -