Draft: [skip ci] Let an administrator choose where GitLab Duo runs in Slack

What does this MR do and why?

A Slack workspace that an administrator installed for the whole instance (self-managed) has no group Owner who can decide where GitLab Duo runs for it, because every group shares the workspace. This MR adds a GitLab Duo section to the Admin area page of that install, where an administrator picks the top-level group, moves GitLab Duo to another group, or turns it off. On an instance with exactly one top-level group the page offers that group with one click.

It builds on !262159 (closed). Only self-managed has instance-wide installs, so this page does not exist on GitLab.com.

What's in it

• Admin::ApplicationSettings::SlackDuoController: PUT /admin/application_settings/slack_duo with a group_id, or without one to turn GitLab Duo off. The workspace comes from the instance install, never from the request. The group has to be a top-level group of the organization.
• MoveService: moving GitLab Duo to another group releases the previous group and claims the new one in one transaction. If the new group cannot take over, the previous group keeps the workspace.
• slack_duo_admin_section.vue (EE): a group picker, confirmations for enabling, moving and turning off, and the shared requirement list with Fix buttons.
• The membership check stays: only members of the chosen group can use GitLab Duo in Slack, also on self-managed. Group Owners see the choice read-only on their pages.

Where this fits

This is one of a stack of merge requests. Each one targets the branch of the one before it, so review and merge them in this order. Audit events and the documentation follow as separate merge requests.

1. !261830 (closed): Table and model
2. !261845 (closed): Services to turn GitLab Duo on or off
3. !262156 (closed): Endpoint and page data
4. !262157 (closed): Mention path
5. !262158 (closed): GitLab Duo section on the integration page
6. !262159 (closed): Claim on the first group install
7. !262160 (closed): Admin area picker (self-managed) (this MR)
8. !262161 (closed): Slack Marketplace install page
9. !262165 (closed): Audit events
10. !262171 (closed): Documentation

Plan and decisions: #633566. Rollout of the feature flag: #633582. Design discussion: gitlab-org#23704.

Context for review agents

• Goal: every GitLab Duo session started from a Slack workspace runs and bills in one top-level group chosen by an Owner (the administrator on self-managed for an instance-wide install), instead of each user's default Duo namespace. Plan: #633566.
• Everything is behind the default-off slack_duo_group feature flag (type wip, becomes beta before rollout, rolled out per top-level group). The Slack flow has its own flag slack_duo_api_flow; DuoGroup.available? requires both for the same group.
• Deliberate decisions, do not flag them unless you find a real defect:
  • One Duo group per workspace (team_id unique), one group can run several workspaces. No organization_id column: namespace_id is the single sharding key. The unique index on team_id holds per cell only, tracked in #633611.
  • A group install claims the workspace, a project install does not. Copies of group or instance installs (inherit_from_id) never let a group claim a workspace. A workspace installed for the whole instance (self-managed only) is the administrator's to assign.
  • An unclaimed workspace has no fallback to the user's default namespace once the flag is on: the user gets a reply that says who can set it up.
  • A Duo group always runs the Slack API flow (slack_assistant/v1), the Developer flow is out. Members of the Duo group only, also on self-managed. Guests pass the membership check and are blocked later, documented as not supported for now.
  • Audit events for enable and disable come in a separate small MR before the flag leaves wip.
• Test world for manual validation: #633566 (comment 4012898135).
• Please look hard at: MoveService (the transaction must leave the previous group in place when the new one fails), that the group has to belong to the admin's organization and be top-level (find_top_level_group_in), and the Current organization handling of admin_current_organization.
• The page follows the feature flags without an actor, because no group exists before an administrator has chosen one. On self-managed the flags are instance-wide.

References

• Implementation issue: #633566
• Design discussion: gitlab-org#23704

Screenshots or screen recordings

Off, then picked.

Moved to another group.

What an Owner sees.

How to set up and validate locally

1. Seed the test world (users, groups and fake Slack installs in every state, no Slack needed): #633566 (comment 4012898135). Run it from your gitlab directory:

   bin/rails runner -e development seed_duo_slack.rb

   It also enables the slack_duo_group, slack_duo_agent and slack_duo_api_flow feature flags. Run it again at any time to reset all GitLab Duo state.

2. Run the web server as self-managed (without GITLAB_SIMULATE_SAAS) and restart it after changing that. The seed creates a fake instance-wide Slack workspace when your GDK has none.

3. Sign in as an administrator and open http://gdk.test:3000/admin/application_settings/integrations/gitlab_slack_application/edit. The GitLab Duo section says it is off and offers a group picker.

   

4. Pick a group, for example sd-a, and confirm. The badge turns to On and the requirements are ready.

   

5. Pick another group and confirm the move. GitLab Duo now runs in the new group, and the previous group no longer has the Slack flow on.

   

6. Sign in as sd-owner (Owner of sd-inst-a, which inherits the instance install) and open http://gdk.test:3000/groups/sd-inst-a/-/settings/integrations/gitlab_slack_application/edit. The Owner sees where GitLab Duo runs but cannot change it.

   

7. Turn GitLab Duo off with Turn off GitLab Duo, confirm, and check the badge returns to Off.

8. Try to break it: while GitLab Duo runs in one group, pick another group that cannot take over (for example a subgroup through the API) and check that the first group keeps the workspace. Open the admin page as a normal user: it answers 404.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.