Skip to content

Viewing push rules in groups should show inherited values

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Problem to solve

When a group Owner/Maintainer views the push rules for a group, and the group is currently inheriting the push rules from a parent group, the view of the push rules is currently wrong - it shows only the globally enabled push rules as turned on, and all other push rules are turned off/blank, instead of the inherited push rules.

This means that:

  • the group owner is unable to find out what the push rules for projects to be newly created in their group effectively are, until they create a project
  • the group owner is unable to edit the push rules for their group starting from the "baseline" of the inherited push rules, and so they may unintentionally turn off push rules by starting their edit from the currently wrong view

Proposal

The group's push rules view/edit form should load the inherited push rules from the closest parent, if there is no push rules created on the group.

There should also be a way to retrieve this via API.

Related issues:

#446051 - bug report about inability to move a group's push rules from empty to null to restore the inheritance from the next closest parent group with push rules, when using in the UI (only possible through API). It was also discussed in comments that there should be a UX solution to displaying this difference between empty and null. However, that's a somewhat different issue from this one, as it only helps with one facet of this scenario, identifying whether an all-empty form is being inherited or not.

Intended users

  • Users with Maintainer/Owner role of a subgroup, could be a developer persona
  • Users with Developer role of a subgroup (or higher, depending on configuration), who is creating projects within a subgroup, could be a developer persona

Feature Usage Metrics

Does this feature require an audit event?

Edited by 🤖 GitLab Bot 🤖