Add option to cascade removal of integrations from group or instance level across subgroups and projects
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Description:
Managing integrations at scale in GitLab becomes cumbersome when dealing with deeply nested group hierarchies and hundreds or thousands of projects. Currently, GitLab does not provide a built-in feature to automatically remove a configured integration from all subgroups and projects when it is removed at the group or instance level.
Problem:
When an integration like Jira is configured at the group level and later removed, only the projects inheriting the default settings are affected. Projects that have overridden the integration settings retain the old configuration, which must be manually removed either via the UI or API.
This causes significant overhead and confusion in large organizations. For example, legacy integrations may continue to push comments or events, resulting in duplicate data or conflicting behaviors in external systems (like Jira).
Proposal:
Introduce a setting or option in the UI and API to allow group or instance administrators to:
- Forcefully remove an integration from the current group or instance.
- Cascade the removal to all subgroups and projects—even if they have overridden the settings.
- Optionally, preview which subgroups or projects will be affected before applying the change.
- Optionally, log the change in audit logs for traceability.
Benefits:
- Reduces manual cleanup effort for large GitLab instances.
- Ensures consistency across project configurations.
- Helps prevent integration conflicts (e.g., duplicate Jira comments from multiple configurations).
- Improves automation and control for administrators managing compliance-sensitive environments.