Draft: [skip ci] Show GitLab Duo for Slack on the integration page

Thomas Schmidtrequested to merge
duo/slack-duo-group-ui into duo/slack-duo-group-mention-path

What does this MR do and why?

Owners need a way to turn GitLab Duo on for their Slack workspace without a console, and everyone else needs to see where it runs and whom to ask. This MR adds a GitLab Duo section to the GitLab for Slack integration page of a group or project. An Owner gets a toggle and the list of what GitLab Duo needs to answer in Slack, with a Fix button or link for each problem. Everybody else sees where GitLab Duo runs and who can change it.

It renders the state of !262156 (closed) and changes nothing for people without the feature flag. The notification settings below it are untouched.

What's in it

  • slack_duo_section.vue (EE): the section, loaded through ee_component, so it does not exist in a FOSS build. The toggle saves on change, separate from the notification form. The server's refusal is shown as it is, for example when another group already runs the workspace.
  • slack_duo_requirements.vue: the requirement list with the right fix for each problem (re-enable the Slack flow, open the GitLab Duo settings, reinstall the app to grant a missing permission). Shared with the Admin area page in a later MR.
  • Read-only states for everyone who cannot change it: off, on here, on in another group (named only if the viewer can see it), managed by an administrator, and several workspaces connected.
  • Two small changes in CE: integration_form.vue renders the section and index.js parses the data. Both only act on the Slack integration.

Copy follows the UX review in gitlab-org#23704: "another group" for a group the viewer cannot see, and "Duo off" means off in Slack only.

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 (this MR)
  6. !262159 (closed): Claim on the first group install
  7. !262160 (closed): Admin area picker (self-managed)
  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: the read-only state logic in slack_duo_section.vue (readOnly, badge), the accessibility (heading level, aria-expanded, labelled icons) and that the CE files only render the section for the Slack integration.
  • The component reads checks defensively and shows the server's message for refusals, or a generic message with Sentry capture for anything else.

References

Screenshots or screen recordings

Duo is off, then on.

Off

On

A requirement fails.

Needs attention with a Fix button

Read-only.

Project page, Duo runs in the group

Another group, not named

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 (password in the seed note) and open the integration page of the group: http://gdk.test:3000/groups/sd-a/-/settings/integrations/gitlab_slack_application/edit

    Duo is off, with a toggle

    There is a GitLab Duo section above the notification settings. GitLab Duo is off and there is a toggle.

  3. Turn the toggle on. The badge turns to On and the requirements show as ready.

    Duo is on and ready

  4. Break a requirement and watch the page react. In rails console: g = Group.find_by_full_path('sd-a'); g.namespace_settings.update!(duo_features_enabled: false). Reload the page: it says Needs attention and lists what is wrong.

    A requirement fails with a link to the settings

    Open GitLab Duo settings opens the group's Duo settings. Turn the setting back on with g.namespace_settings.update!(duo_features_enabled: true).

  5. Open the project page as the same user: http://gdk.test:3000/sd-a/web/-/settings/integrations/gitlab_slack_application/edit. It is read-only and points to the group page.

    The project page points to the group page

  6. Sign in as sd-maint (Maintainer). The group page is not reachable (404), the project page shows who to ask.

    A Maintainer is asked to contact an Owner

  7. With Duo on in sd-a, sign in as sd-owner2 and open http://gdk.test:3000/groups/sd-other/-/settings/integrations/gitlab_slack_application/edit. sd-owner2 cannot see sd-a, so the page says GitLab Duo runs in "another group" without naming it. As sd-owner, who can see both, the same page names sd-a and links to it.

    Another group runs it, the name is not shown Another group runs it, the viewer can see it

  8. Open http://gdk.test:3000/groups/sd-multi/-/settings/integrations/gitlab_slack_application/edit. The projects of this group connect two Slack workspaces, so there is nothing to guess: the page asks to install the app on the group and lists where the workspaces are connected.

    Several workspaces are connected

  9. Check the SaaS variant: restart the web server with GITLAB_SIMULATE_SAAS=1 and reload. The pages are the same. The difference is for a workspace installed for the whole instance, which only exists on self-managed: http://gdk.test:3000/groups/sd-inst-a/-/settings/integrations/gitlab_slack_application/edit says that the administrator decides, and links to the Admin area for administrators.

    Instance-wide workspace, Owner

  10. Turn the flag off (Feature.disable(:slack_duo_group), the flag state is cached for about a minute): the section disappears and the page is as before. Enable it again afterwards.

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.

Edited by Thomas Schmidt

Merge request reports