Enable duo_admin_access_rules_subgroups by default

Pratyaksh Golashrequested to merge
628453-enable-duo-admin-access-rules-subgroups-by-default into master

What does this MR do and why?

This MR enables the feature flag duo_admin_access_rules_subgroups by default. It changes default_enabled: false to default_enabled: true in ee/config/feature_flags/beta/duo_admin_access_rules_subgroups.yml. The flag stays type beta. Beta flags may be enabled by default under the feature flag lifecycle.

On GitLab Self-Managed and GitLab Dedicated, the instance administrator page Admin > GitLab Duo > Configuration has a section called "Restrict access based on group membership". The group picker there offered only top-level groups. With the flag on, the picker also lists subgroups, each shown with its full path. Only the picker is gated by this flag. The backend changes that shipped with the feature already apply for everyone regardless of the flag: accepting subgroup ids, rejecting non-group namespaces and duplicates, and showing subgroup rules that used to be hidden on the page.

GitLab.com does not use this page. The instance-level Duo configuration page is hidden on GitLab.com, so a GitLab.com rollout cannot exercise the feature. Self-Managed instances read default_enabled when they have no Flipper record for the flag. GitLab Dedicated does not support feature flags at all, so Dedicated tenants only get the feature once default_enabled is true, per enabling features on Dedicated. Enabling by default is the step that actually delivers the feature to customers.

The flag is kept rather than removed so administrators keep a kill switch. Running Feature.disable(:duo_admin_access_rules_subgroups) in the Rails console returns the picker to top-level groups only. Existing subgroup rules stay listed and enforced either way.

The feature was introduced in !255453 (merged), merged 2026-09-18, milestone 19.5. Documentation for the feature merged in !256195 (merged).

This MR also updates doc/administration/gitlab_duo/configure/access_control.md. The history entry for the feature now ends "Enabled by default." instead of "Disabled by default." Introduction and default-on both land in GitLab 19.5, so a single history entry is used rather than adding a separate "Enabled on GitLab Self-Managed and GitLab Dedicated in GitLab 19.5" line next to a "Disabled by default" entry for the same release. The body sentence that described both flag states, "If you enable the duo_admin_access_rules_subgroups feature flag, you can select any top-level group or subgroup. Otherwise, you can select only top-level groups.", is replaced with "You can select any top-level group or subgroup." The [!flag] alert stays because the flag still exists.

What does not change

  • No production code changes.
  • No spec changes. In RSpec an unstubbed flag is forced on regardless of default_enabled, per spec/support/helpers/stubbed_feature.rb. Existing stub_feature_flags(duo_admin_access_rules_subgroups: false) blocks behave as before.
  • Nothing changes on GitLab.com.
  • No database change, no migrations, no database review needed.

Review notes

  • Approvals: backend maintainer approval is required for ee/config/feature_flags/ per .gitlab/CODEOWNERS. The Documentation Pages section is optional; the page lists @ashrafkhamis and @fneill as its technical writers.
  • Runtime consumers of the flag, both unchanged: push_frontend_feature_flag(:duo_admin_access_rules_subgroups, :instance) in ee/app/controllers/admin/gitlab_duo/configuration_controller.rb and the topLevelOnly argument in ee/app/assets/javascripts/ai/settings/components/group_selector.vue.
  • Live-instance verification https://gitlab.com/gitlab-org/gitlab/-/work_items/630255 (confidential) asks an administrator of a real Self-Managed instance to run the feature with the flag on. Not run yet. This MR can stay in Draft until it passes.

How to set up and validate locally

  1. Rails console: Feature::Definition.get(:duo_admin_access_rules_subgroups).to_h shows type: "beta" and default_enabled: true.
  2. Rails console: run Feature.remove(:duo_admin_access_rules_subgroups), then Feature.enabled?(:duo_admin_access_rules_subgroups, :instance) returns true on this branch and false on master.
  3. UI: as an administrator, in the upper-right corner select Admin. In the left sidebar select GitLab Duo, then select Change configuration. Under Restrict access based on group membership, select Add group. The dropdown lists subgroups with their full paths, without setting any flag.

Checks run locally:

  • spec/lib/feature/definition_spec.rb: 41 examples, 0 failures.
  • ee/spec/requests/admin/gitlab_duo/configuration_controller_spec.rb: 12 examples, 0 failures.
  • ee/spec/frontend/ai/settings/components/group_selector_spec.js: 29 tests passed.
  • markdownlint-cli2 on the docs page: 0 issues.
  • vale --minAlertLevel suggestion on the docs page: 0 errors, 0 warnings.

References

MR acceptance checklist

This MR meets the definition of done.

Merge request reports