<!--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=372412) </details> <!--IssueSummary end--> ## About After https://gitlab.com/groups/gitlab-org/-/epics/8670 the Slack Application integration has the notifications capability of the separate Slack Notifications integration. The old Slack Notifications integration will be deprecated in https://gitlab.com/gitlab-org/gitlab/-/issues/372411 and eventually, we are likely to want to remove it altogether. ## Proposal To make it simple for users of existing Slack Notifications integration to migrate to the Slack App integration, we want to allow them to automatically migrate their existing settings to the Slack Application integration (SaaS-only users until https://gitlab.com/groups/gitlab-org/-/epics/1211). Users will always need to manually initiate this migration because part of it involves authorizing the Slack App. The UX flow for this feature is: 1. Display buttons to allow users to migrate the settings in their active Slack Notifications integration to the Slack App integration: 1. On the integrations index page (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_41.png) 1. On the Slack Notifications integration page (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_17.png). 2. Migration would initiate the existing Slack App integration install/reinstall flow (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_21.png). 3. When the flow completes the Slack Notifications integration settings would be brought across to the Slack App integration (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_24.png), and the old Slack Notifications integration would be disabled. Once the GitLab for Slack app integration is enabled at group and instance-level https://gitlab.com/gitlab-org/gitlab/-/issues/391526, this migration would need to work at group and instance-level also: For example, the settings from a group-level Slack notifications integration could be copied across to a group-level GitLab for Slack app integration, and similar for instance-level. If the project/group/instance already has a Slack App integration created, we would warn them that doing the migration will override the notification settings of the Slack App integration: 1. In the notice that displays the migration buttons (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_28.png) 2. As a modal that displays after clicking the button to confirm they understand (see design https://gitlab.com/gitlab-org/gitlab/-/issues/335673/designs/Frame_43.png) ## Initial technical thoughts The backend will be able do the migration by copying the notifications settings from a Slack Notifications integration to a Slack App integration. We can create a new Slack App integration, or update an existing one. We can then deactivate the old Slack Notifications integration for the project. Something to resolve is how to pass a message from the beginning of the Slack App installation flow to the end to signal that settings from a Slack Notifications integration should be copied to the Slack App integration. We need to test the scenario that instance or group-level migrations propagate down to project-level after https://gitlab.com/gitlab-org/gitlab/-/issues/391526. Perhaps the simplest way is regardless of whether the "migrate" button was clicked or not, always check if there is an active Slack Notifications integration for the project in the final step of the creation of a Slack App integration, and if so, we always copy the settings across and display a flash notification to say we've done this, and always disable the active Slack Notifications integration. This means we would migrate them even if they had not clicked the "migrate" button. However, it probably makes sense to always do this anyway, as they would not want both active integrations, and "forcing" the migration is probably fine and sensible. ## Designs - :frame_photo: Flow: [User only has Slack notifications enabled](https://www.figma.com/proto/TU7XWkuFMBX1ODckT89ryT/Slack-migration-flow?page-id=31%3A5138&node-id=31%3A5391&viewport=1547%2C768%2C0.18&scaling=min-zoom&starting-point-node-id=31%3A5391) - :frame_photo: Flow: [User has Slack notifications and theGitLab for Slack app enabled](https://www.figma.com/proto/TU7XWkuFMBX1ODckT89ryT/Slack-migration-flow?page-id=31%3A5138&node-id=31%3A5393&viewport=1707%2C649%2C0.21&scaling=min-zoom&starting-point-node-id=31%3A5393&show-proto-sidebar=1) - :pencil2: [Figma source project](https://www.figma.com/file/TU7XWkuFMBX1ODckT89ryT/Slack-migration-flow?node-id=31%3A5391&t=gFFS9JCV0EpcMhHZ-1) ### Availability & Testing Suggestion: * feature specs around the migration flow cases. (stubbing out slack auth) * add slack notification tests at the e2e layer. <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning -->