Virtual registry settings toggle disappears once disabled, blocking re-enablement

Summary

The Enable virtual registry toggle on the group Settings > Packages and registries page is rendered inside a section that is only shown when the feature is already enabled. Once a group Owner toggles virtual registry off, the entire settings section (and its toggle) disappears on the next page load, so the feature cannot be re-enabled through the UI.

Steps to reproduce

  1. As a group Owner, ensure virtual registry is available for the group (packages_virtual_registry / container_virtual_registry license, dependency proxy available, and the maven_virtual_registry / container_virtual_registries feature flag enabled).
  2. Go to Group > Settings > Packages and registries. The Virtual registry section shows the Enable virtual registry toggle.
  3. Toggle Enable virtual registry off. The setting saves successfully (Settings saved successfully.).
  4. Reload the settings page.

Current behavior

The Virtual registry section no longer renders, so there is no toggle to turn the feature back on. Re-enabling requires the GraphQL updateVirtualRegistriesSetting mutation or a direct database change.

Expected behavior

The settings section and toggle should always render while the feature is available (license + feature flag + dependency proxy + :admin_virtual_registry permission), regardless of whether it is currently enabled, so an Owner can toggle it back on.

Root cause

show_virtual_registries_setting? (ee/app/helpers/ee/groups/settings_helper.rb) gates rendering on VirtualRegistries.any_registry_available?, which resolves through each registry's feature_enabled? - and feature_enabled? includes VirtualRegistries::Setting.enabled_for_group?. The visibility of the settings section was thereby coupled to the current on/off state.

This was introduced in !226797 (merged) (Consolidate virtual registry availability checks with memoization), which rewired the visibility helper onto the runtime feature_enabled? gate. Before that change, show_virtual_registries_setting? performed an availability-only check (feature flag + license + permission) and did not consult the enabled state.

The permission layer is not implicated: :admin_virtual_registry is a static Owner grant (config/authz/roles/owner.yml) and VirtualRegistries::Policies::GroupPolicy does not reference the enabled state. The only coupling is the Setting.enabled_for_group? term reached via feature_enabled?.

Proposed fix

Decouple section visibility from the enabled state: render the section based on feature availability (license + feature flag + dependency proxy + :admin_virtual_registry) without the Setting.enabled_for_group? term, while leaving feature_enabled? (the runtime gate used by the registry APIs and the registry list/cleanup pages) unchanged.

Workaround

Until the fix ships, a group Owner can re-enable the feature with the updateVirtualRegistriesSetting GraphQL mutation. This works even while the section is hidden, because the mutation is gated only on the feature flag, license, and admin_virtual_registry permission, not on the current enabled state.

In the GraphQL explorer (https://gitlab.com/-/graphql-explorer, or <your-instance>/-/graphql-explorer on GitLab Self-Managed), signed in as a group Owner, run:

mutation {
  updateVirtualRegistriesSetting(input: { fullPath: "<group-full-path>", enabled: true }) {
    virtualRegistriesSetting {
      enabled
    }
    errors
  }
}

Replace <group-full-path> with the top-level group path (for example, my-group). When enabled returns true and errors is empty, reload the settings page; the Virtual registry section and toggle are visible again.

Edited by Rahul Chanila