Add group setting for web search in Duo Chat

Rafa Fredericorequested to merge
587234-group-web-search-setting-backend into master

This merge request adds the backend for a group owner setting that allows or forbids web search in GitLab Duo Chat. The setting lives at Group, Settings, GitLab Duo, Configuration, in the existing "Data privacy" subsection, and is off by default.

GitLab Duo Chat only knows its training data and GitLab context, so it gives stale answers about current package versions, vulnerability advisories, and deprecations. Web search fixes that, but it sends the user's question to an external search provider, which is a compliance decision that belongs to the group owner. The epic &20480 specifies a two-layer control model: an admin toggle for intent, and network domain allowlists for enforcement. This merge request is the admin toggle. Developers separately opt in per conversation from the chat input, which already shipped.

This is the first merge request in a three-merge-request stack. The branch is 587234-group-web-search-setting-backend and it targets master. The second merge request in the stack, !253620, is stacked on top of this one and must merge after it, the third one !253676 gates the feature on prompt area based on the configuration the 2 first MRs setup.

What this MR contains

  • A web_search_enabled boolean column on the namespace_ai_settings table, default false, not null. Regular migration, milestone 19.4.
  • Model validation on Ai::NamespaceSetting, plus a validation that rejects the setting on subgroups and personal namespaces, since it is a top-level-group setting. This mirrors the existing AI Catalog restriction on the same table.
  • Delegation on Namespace.
  • A web_search_enabled parameter in the ai_settings_attributes block of the group settings REST API, and the matching field on the AiSettings response entity.
  • A webSearchEnabled field on the AiNamespaceSettings GraphQL type, for the workflow service and other API consumers.
  • A web_search_enabled_updated audit event, matching every other setting on this table.
  • Two data attributes the settings page reads: web_search_enabled and web_search_available.
  • Regenerated GraphQL reference docs, GraphQL introspection schema, OpenAPI v2 and v3, and the audit event types doc.

The pattern for this change follows !216829 (merged) and !217061 (merged).

Points a reviewer will ask about

Danger warns that new model validations can break existing records. They cannot here. The column is not null with a default of false, so every existing row already satisfies the inclusion validation. The top-level-group validation only runs when the value changes, and it never changes for existing rows.

web_search_available deliberately omits the feature flag check, unlike the neighboring prompt_injection_protection_available, which folds Feature.enabled? into the same expression. The frontend owns the dap_web_search gate, so the flag is evaluated in exactly one place. There is a code comment saying so.

The new GraphQL field carries no @gl_introduced directive because no frontend code reads it. The settings page loads its values from Rails data attributes and saves through the REST API, so the field exists only for the workflow service and other API consumers.

Runtime enforcement is not part of this MR

Nothing enforces the setting at runtime yet. The workflow create mutation, the web search update mutation, and the chat menu item all still check only the feature flag against the user. Honoring the group setting at runtime is a separate follow-up, and until it lands the setting records intent without changing behavior.

Testing done

Model, namespace delegation, settings helper, REST request, response entity, GraphQL type, and audit event specs all pass. Rubocop is clean. All pre-push hooks pass, including the database migration checksum, schema change, migration name collision, OpenAPI, GraphQL docs, GraphQL introspection, and audit event types doc checks.

Stack

This work is a three merge request stack:

  1. Backend, the group setting itself: !253643 (merged)
  2. Frontend, the group settings checkbox: !253620
  3. Honouring the setting in the chat UI: !253676

They must merge in that order.

References

Video recording

Edited by Rafa Frederico

Merge request reports