Draft: [skip ci] Offer top-level groups on the GitLab for Slack install page

What does this MR do and why?

People find the GitLab for Slack app in the Slack Marketplace and land on /-/profile/slack/edit to connect it to GitLab. This MR lets them install on a top-level group they own, listed above the projects they maintain, and says what each choice does for GitLab Duo: a group install claims the Slack workspace for that group, a project install only connects notifications and commands. When an administrator installed the workspace for the whole instance, the page says that the administrator decides where GitLab Duo runs for it.

With the feature flag off the page is as before. It builds on !262160 (closed).

What's in it

• Install target dropdown with two sections, groups first and projects second, a search field that narrows both while you type (people who own many groups need it), and a hint for the selected target. The groups section only shows for people who own a top-level group.
• slack_link accepts a group_id. It refuses groups the user does not own and subgroups, because only a top-level group can run GitLab Duo.
• A notice for the instance-wide case: "X is connected for the whole instance. Your administrator chooses where GitLab Duo runs for it", with a link to the Admin area for administrators. No per-group promise next to it.
• CE helpers (slack_install_groups_data, slack_instance_workspace_data, slack_duo_group_picker?) are private no-ops that EE overrides, so a FOSS build is unchanged.

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)
8. !262161 (closed): Slack Marketplace install page (this MR)
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: installable_groups (top-level, owned groups only), that FOSS builds are unchanged (the CE helper methods are private and return nothing), and the serialization of instance_workspace (a missing workspace must not become the string "null").
• The group list is not limited: owners of very many top-level groups are rare. Say if you want a limit with search.

References

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

Screenshots or screen recordings

Self-managed, instance-wide workspace: a notice and no promise for the group.

Search narrows the list.

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. Sign in as sd-owner (Owner of several top-level groups) and open http://gdk.test:3000/-/profile/slack/edit.

3. Open the dropdown. Groups are listed first, projects second. Select a group.

   

   • Self-managed with an instance-wide workspace: a notice says that the workspace is connected for the whole instance and that the administrator chooses where GitLab Duo runs. There is no promise about the group.
   • GitLab.com (restart the web server with GITLAB_SIMULATE_SAAS=1): no notice, and the hint under the dropdown says that GitLab Duo will run in the selected group if the workspace has no GitLab Duo group yet.

4. Type part of a group or project name into the search field: both sections narrow while you type, and an empty result says so. Clear it to see everything again.

5. Select a project instead. The hint says that a project install does not turn GitLab Duo on and that an Owner of the top-level group can do that later. Projects whose group already has the app installed are not listed, because they count as installed.

6. Press Continue with a group selected. The browser goes to Slack, and the redirect target in the URL is the group's slack_auth page (/groups/sd-a/-/settings/slack/slack_auth).

7. Sign in as sd-dev (owns no group): the page is as before, only the project list. Turn the flag off (Feature.disable(:slack_duo_group), cached for about a minute) and the page is as before for everyone.

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.