Change-gate AI settings in group Duo settings form

SAM FIGUEROArequested to merge
sf/fix/change-gate-duo-settings-form-629075 into master

What does this MR do and why?

The group Duo settings form (ee/app/assets/javascripts/ai/settings/pages/ai_group_settings.vue) sent six ai_settings_attributes keys on every save, regardless of whether the user changed them:

  • duo_agent_platform_enabled
  • duo_workflow_mcp_enabled
  • ai_usage_data_collection_enabled
  • ai_catalog_restricted_to_group_hierarchy
  • prompt_injection_protection_level
  • foundational_agents_default_enabled

duo_agent_platform_enabled is stored through jsonb_accessor in feature_settings, where the presence of a key means "explicitly set". Saving any unrelated toggle on this page therefore wrote the key and permanently marked the setting as configured.

This MR extends the change-gated spread pattern already used in the same method (for include_recommended_allowed, allow_all_unix_sockets, allow_project_extension, and the minimum access levels) to those six keys. Each key is now included only when its current form value differs from the injected initial value. The duoWorkflowAvailable and promptInjectionProtectionAvailable guards are kept and AND-ed with the change check.

No backend change is needed: every key under ai_settings_attributes is Grape optional in ee/lib/ee/api/helpers/groups_helpers.rb, and accepts_nested_attributes_for :ai_settings, update_only: true skips absent keys. Event publishers and Namespaces::AiNamespaceSettingChangesAuditor rely on dirty tracking, so omitting unchanged values does not alter their behaviour.

This is slice 1 of https://gitlab.com/groups/gitlab-org/-/work_items/23594 (frontend only).

References

Screenshots or screen recordings

No visible UI change; only the request payload differs.

Before After
ai_settings_attributes always contains all six keys ai_settings_attributes contains only keys whose value changed

How to set up and validate locally

  1. Open a group's Duo settings page: http://gdk.test:3000/groups/<group>/-/settings/gitlab_duo/configuration (or the GitLab Duo section on /groups/<group>/-/edit).
  2. Open the browser dev tools Network tab.
  3. Change one setting that is not part of ai_settings_attributes (for example, the "Experiment and beta features" checkbox) and save.
  4. Inspect the PUT /api/v4/groups/<id> request body: ai_settings_attributes should be empty (or contain only keys for settings you changed).
  5. Optional, in a Rails console, confirm the jsonb key was not written: 
    Group.find_by_full_path('<group>').ai_settings.feature_settings.key?('duo_agent_platform_enabled')
  6. Change the "Allow external MCP tools" checkbox only and save: the request body should contain exactly ai_settings_attributes: { duo_workflow_mcp_enabled: <value> } (plus any minimum access level keys the child form reports as changed).

Verification note (acceptance criterion)

No non-Vue form posts ai_settings_attributes. Searched ee/app/views, ee/app/components, and all HAML under ee/app for ai_settings_attributes and for the five keys permitted in ee/app/controllers/concerns/ee/groups/params.rb; there are no matches. The only client is this Vue component, which submits through the REST API (PUT /api/v4/groups/:id), not the Rails controller.

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