Slack workspaces re-linked on descendant integrations does not use custom settings
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
If a user removes a Slack workspace from a GitLab for Slack App integration on a group with descendant groups and projects that use its settings and re-links the workspace to a descendant group/project, the descendant integration is still treated as inheriting settings from the original group even though it's no longer active. This results in settings not appearing or being editable, even though the integration is still active and the inherited settings were not lost:
Steps to reproduce
- Enable the integration at the group level
- Configure the triggers
- Unlink the workspace
- Go to a descendant project
- Manually link the workspace
- The triggers do not show up, even though they're present in the database. (Not sure if this happens because the parent is disabled and the integration is inherited.)
What is the current bug behavior?
Removing a Slack workspace from a higher-level group and moving it to a descendant group/project does not treat the descendant integration as using custom settings.
What is the expected correct behavior?
Linking a Slack workspace to a disabled GitLab for Slack App integration should treat it as if it were activated like any other integration. I.e., it should no longer inherit from another integration and should use custom settings.
Output of checks
This bug happens on GitLab.com, but can be worked around by selecting "Use custom settings" dropdown option and saving the integration. No settings from the original inheritance are lost.
Possible fixes
SlackIntegrations are linked for the first time to a Integrations::GitlabSlackApplication in the Integrations::SlackInstallation::BaseService. It may be possible to break the inheritance chain on installation here