Allow overriding certain fields in inherited integration settings
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
With the current architecture for instance-/group-level integrations, the inheritance of settings is all-or-nothing: Projects can either be set to "Use default settings" and inherit all settings from the parent, or "Use custom settings" but then have to redefine all settings.
It's often desirable to set common settings (such as URLs and authentication credentials) on the toplevel, and then set project-specific settings (such as Jira project keys) on the project level.
We need a mechanism to allow overriding only certain fields. Initially this could be a hard-coded list, but later we might also need ways to let users decide this on a per-field basis (allow/block overriding).
Intended users
User experience goal
Proposal
We could start with the Jira issue settings, i.e. all the fields below the "View Jira issues in GitLab" heading.
These are currently hidden on the instance/group level because some of the code relies on having a project context.
We also have a bug where these fields are currently not disabled when inheritance is active, so it's actually already possible to override them, but with some bugginess (the UI doesn't always correctly reflect the state, and changing the settings on the parent will override the custom values again). See #327113 (closed) for more details.