### Summary On GitLab Self-Managed EE 19.3.2, a top-level group's **Settings \> GitLab Duo** page returns 404 and its sidebar tab is absent. The page is gated behind a GitLab.com-only subscription check, so no license tier, Duo add-on, or instance-level setting can surface it. This is the documented entry point for enabling group-level AI audit event storage and for the AI governance view, both of which are documented as available on GitLab Self-Managed. The gating is **inconsistent across the child pages**: - The `Governance` child is **not** SaaS-gated and renders (it even appears as an orphaned `Governance` item in the Settings sidebar with no parent — split out to a linked issue). - The `Configuration` child, which holds the documented group-level **Store AI audit events** toggle, redirects into the 404 parent and is unreachable by any UI route. ### Steps to reproduce 1. Self-managed EE 19.3.2, a license tier that includes Duo, self-hosted Duo Agent Platform, AI audit events enabled at the instance level. 2. As an instance administrator and group Owner, on a real top-level group, open `https://<INSTANCE_HOST>/groups/<GROUP_PATH>/-/settings/gitlab_duo`. 3. Observe 404. Observe there is no **Settings \> GitLab Duo** item in the group sidebar. 4. Follow the documented path in the [AI audit events docs](https://docs.gitlab.com/user/ai-governance/ai-audit-events/): group **Settings \> GitLab Duo \> Change configuration**, to enable **Store AI audit events** at the group level. The `/-/settings/gitlab_duo/configuration` route redirects to the parent Duo path, which 404s. ### Current behavior Observed live on a self-managed EE 19.3.2 instance, as instance administrator and group Owner, against a real top-level group: | `/groups/<GROUP_PATH>/-/settings...` | Observed | |--------------------------------------|----------| | `/gitlab_duo` | HTTP 404 | | `/gitlab_duo/configuration` | HTTP 302 → `/gitlab_duo` → 404 | | `/gitlab_duo/seat_utilization` | HTTP 302 → `/gitlab_duo` → 404 | | `/gitlab_duo/governance` | **HTTP 200, renders** | | `/gitlab_duo/model_selection` | HTTP 404 (ability gate, not SaaS) | | `/edit` (group General) | HTTP 200, contains a "GitLab Duo features" section | Group Settings sidebar, enumerated from the rendered nav: - **No "GitLab Duo" item.** - **A "Governance" item is present**, linking to `/-/settings/gitlab_duo/governance`, sitting directly in the Settings list with no "GitLab Duo" parent above it. Net effect: - Viewing AI audit events / AI governance still works, but only through the orphaned "Governance" tab, not the documented `GitLab Duo > Change governance` path. - **Group-level Duo configuration, including the documented `Store AI audit events` cascade toggle under `Change configuration`, is unreachable**: no sidebar entry, and the direct URL redirects into the 404 parent. The project-level toggle under **Settings \> General \> GitLab Duo** is the only working path, and it cannot set or lock the group-level cascade. Note on `seat_utilization`: the action body has `render_404 unless show_gitlab_duo_settings_menu_item?`, but the earlier `before_action :ensure_seat_assignable_duo_add_on!` redirects to the parent Duo path first when there is no active seat-assignable Duo add-on, which is what produces the observed 302 → 404 rather than a direct 404. So not every observed status code is attributable to the SaaS gate. ### Expected behavior On self-managed with a Duo-inclusive license, the top-level group **Settings \> GitLab Duo** page and sidebar tab should be reachable, so that the documented group-level AI audit event storage and governance controls are usable — consistent with the AI audit events documentation listing `GitLab Self-Managed` as a supported offering. ### Root cause (verified against `v19.3.2-ee`) The nav gate is SaaS-only: ```ruby # ee/lib/nav/gitlab_duo_settings_page.rb def show_gitlab_duo_settings_menu_item?(group) group.usage_quotas_enabled? && show_gitlab_duo_settings_app?(group) end def show_gitlab_duo_settings_app?(group) gitlab_com_subscription? && gitlab_duo_subscription_valid?(group) end ``` ```ruby # ee/app/helpers/gitlab_subscriptions/subscription_helper.rb def self.gitlab_com_subscription? ::Gitlab::Saas.feature_available?(:gitlab_com_subscriptions) end ``` `gitlab_com_subscription?` is false on every self-managed instance, and `&&` short-circuits, so `gitlab_duo_subscription_valid?` never runs. `Group#usage_quotas_enabled?` is `root?`, so a top-level group already satisfies the other half; **the SaaS check is the sole blocker**. The same helper backs the sidebar item (returned as `Sidebars::NilMenuItem` when the check fails) and the `show`, `configuration`, and `seat_utilization` controllers under `ee/app/controllers/groups/settings/gitlab_duo/`. Notably, the sibling `governance_controller` and `model_selection_controller` do **not** use this helper. `governance_controller#index` gates on: ```ruby group.root? && group.licensed_ai_features_available? && Feature.enabled?(:gitlab_duo_governance_settings, group) && can?(current_user, :read_ai_tool_rule, group) ``` with no SaaS check. So the governance page renders on self-managed while its parent page and sidebar entry are hidden. **The gating between the parent entry point and its self-managed-relevant sub-pages is inconsistent, which suggests the parent gate is an oversight rather than a deliberate SaaS-only product decision.** ### Why severity::2 The read path survives via the orphaned Governance tab, so this is not a total loss of function. But the group-level **Store AI audit events** cascade/lock control is unreachable by _any_ UI route on self-managed, and the project-level fallback cannot set or lock a cascade. A documented compliance control therefore cannot be exercised at the group level at all on an offering where the docs say it is available. Happy to be talked down to ~&quot;severity::3&quot; if there is a supported API or Rails-console path that sets the group-level cascade — that would make this a UI-reachability bug rather than a functional gap. ### Documentation mismatch https://docs.gitlab.com/user/ai-governance/ai-audit-events/ lists: - `Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated` - `Tier: Premium, Ultimate` and documents the group flows as **Settings \> GitLab Duo \> Change governance** (to view events) and **Settings \> GitLab Duo \> Change configuration \> Data and privacy \> Store AI audit events** (to enable storage). Both group flows start at **Settings \> GitLab Duo**, which does not exist on self-managed. Either the code gate or the docs navigation needs to change. If this bug is fixed, the docs become correct automatically. If the SaaS gate is deemed intentional, the docs should instead document the working self-managed path (project-level toggle, and the direct governance URL) and the offering badge should be corrected. ### Environment - GitLab Self-Managed EE 19.3.2 - Verified against source at tag `v19.3.2-ee` - Runtime behavior verified live on an EE 19.3.2 instance (statuses and sidebar as above) - License includes Duo; self-hosted Duo Agent Platform; instance-level AI auditing enabled ### Source references (all at `v19.3.2-ee`) - `ee/lib/nav/gitlab_duo_settings_page.rb` - `ee/app/helpers/gitlab_subscriptions/subscription_helper.rb` - `app/models/group.rb` (`usage_quotas_enabled?`) - `ee/lib/ee/sidebars/groups/menus/settings_menu.rb` (`gitlab_duo_settings_menu_item`, `governance_menu_item`) - `ee/app/controllers/groups/settings/gitlab_duo_controller.rb` - `ee/app/controllers/groups/settings/gitlab_duo/configuration_controller.rb` - `ee/app/controllers/groups/settings/gitlab_duo/seat_utilization_controller.rb` - `ee/app/controllers/groups/settings/gitlab_duo/governance_controller.rb` - `ee/app/controllers/groups/settings/gitlab_duo/model_selection_controller.rb` - `ee/config/feature_flags/beta/gitlab_duo_governance_settings.yml` (`default_enabled: true`, `milestone: '19.0'`) - Docs: https://docs.gitlab.com/user/ai-governance/ai-audit-events/ ### Open question for the engineering owner Should the top-level group GitLab Duo settings entry point (`show_gitlab_duo_settings_app?`) remain gated on `gitlab_com_subscription?`, given that its governance and configuration sub-pages, and the AI audit events storage feature they gate, are documented and built for self-managed? If some cards on that page are genuinely SaaS-only (seat utilization, add-on management), should the SaaS gate move **to those cards**, so the page itself and the self-managed-relevant controls become reachable on self-managed? ### Secondary defect (self-contained) `configuration_controller#index` redirects to `group_settings_gitlab_duo_path` when `render_configuration_page?` is false. On self-managed that target 404s, so the redirect lands on an error page rather than a meaningful state. Worth fixing independently even if the main gate question is deferred. ### Related issues - #628876 — AI Governance dashboard 404s when Duo is "Off by default" in the top-level group. Same page, same status code, **different cause** (availability setting, reproduced on GitLab.com). Not a duplicate. - #510679 — self-managed 17.7, group Duo settings missing and `/-/settings/gitlab_duo` 404s. Closed in 17.8. Worth confirming whether that fix was intended to cover self-managed; if so, this may be a regression rather than a never-implemented surface. - #597964 — open docs/UI inconsistency for self-managed Duo settings surfaces. /cc @gitlab-bot