Add building blocks for GitLab Duo in Slack Duo groups

Thomas Schmidtrequested to merge
duo/feature/633566-slack-duo-group-building-blocks into master

What does this MR do and why?

Adds three inert building blocks for "GitLab Duo in Slack: one Duo group per Slack workspace" — MR 2 of 8, split from the reference implementation at !262856 (closed). Nothing here changes behavior: no caller uses any of it until the mention-path MR (MR 4 of 8).

  1. requires_enablement on Ai::Catalog::FoundationalFlow (ee/app/models/ai/catalog/foundational_flow/attributes.rb): a new boolean attribute, default true, with a runs_as_user_without_enablement validation that allows false only for flows with coding_environment: 'none'. A flow no group enables is not listed in flow settings and gets no consumers, so it can only run as the user. No flow sets requires_enablement today, so the default true keeps every flow's behavior unchanged. (The one flow that will set it false — slack_assistant/v1 — moves to a later MR because it changes behavior with the flag off.)

  2. Integrations::SlackWorkspace::DuoRequirements (ee/app/models/integrations/slack_workspace/duo_requirements.rb): the group settings GitLab Duo needs in the Duo group to answer in Slack (Duo features on, Agent Platform on, experiment/beta features on), plus where each failure is fixed (group vs. instance settings) and whether seats are required. The requirements card and the mention path's refusal replies will share these checks.

  3. Ai::Messaging::Adapters::Slack::DuoGroupReplies (ee/app/services/ai/messaging/adapters/slack/duo_group_replies.rb): the Slack reply strings for a refused mention. Each reply says which setting refused and who can fix it, and with_group falls back to an unnamed variant when the group name must not leak to someone who can't see the private group.

Each Slack workspace runs GitLab Duo in one top-level group (the "Duo group"). When a mention is refused, the Slack reply must name the refusing setting and its owner without exposing groups the user can't see — these three pieces carry that.

References

  • Implementation issue: #633566
  • Reference implementation (source of truth, not to merge): !262856 (closed) (branch duo/slack-duo-group-v2)
  • Follows: MR 1 of 8 (installations schema); callers arrive in the mention-path MR (MR 4 of 8)

Screenshots or screen recordings

No UI change. All code is unused in this MR; the Slack replies and requirements card ship in later MRs.

How to set up and validate locally

Nothing to validate manually — this MR is inert by design. The new model attribute, DuoRequirements, and DuoGroupReplies have no callers until the mention-path MR (MR 4 of 8). Reviewers can inspect the new files and their specs:

  • ee/app/models/ai/catalog/foundational_flow/attributes.rb + ee/spec/models/ai/catalog/foundational_flow_spec.rb
  • ee/app/models/integrations/slack_workspace/duo_requirements.rb + ee/spec/models/integrations/slack_workspace/duo_requirements_spec.rb
  • ee/app/services/ai/messaging/adapters/slack/duo_group_replies.rb + ee/spec/services/ai/messaging/adapters/slack/duo_group_replies_spec.rb

Request for technical writing review: the Slack reply strings in ee/app/services/ai/messaging/adapters/slack/duo_group_replies.rb are user-facing and new. Please review wording, tone, and that each refusal names the setting and who can fix it.

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.

Merge request reports