## Summary On a self-managed instance with a Premium/Ultimate license (`:orbit` licensed) and the `knowledge_graph` feature flag enabled, no user (including the instance admin / root) can enroll a namespace into Orbit indexing through the UI. `/dashboard/orbit` shows the empty state *"Orbit requires a top-level group with at least a Premium license."* even when the instance is licensed, and `/admin/orbit` renders every "Turn on indexing" button disabled. The only working path today is a Rails console command. I reproduced this on a live self-managed GDK (Ultimate license, root is Owner on all groups): the UI blocks enrollment, but the console command populates the dashboard, so it's a policy gate, not a license or indexing problem. ## Steps to reproduce 1. Self-managed instance, Premium or Ultimate license (`:orbit` available). 1. As admin, enable the flag: `Feature.enable(:knowledge_graph)`. 1. Log in as **root**, visit `/dashboard/orbit`. 1. **Expected:** ability to enroll a top-level group. 1. **Actual:** empty state *"Orbit requires a top-level group with at least a Premium license."*. On `/admin/orbit`, every "Turn on indexing" button is disabled. 1. Workaround that proves it's authz, not data/licensing: ```ruby Namespace.where(type: 'Group', parent_id: nil).find_each do |ns| Analytics::KnowledgeGraph::EnabledNamespace.find_or_create_by!(root_namespace_id: ns.id) end ``` Direct model writes succeed and the dashboard populates immediately. ## Root cause Every UI enrollment path funnels through the group ability `:update_knowledge_graph_setting`, and that ability is prevented on self-managed with no admin/root override: ```ruby # ee/app/policies/ee/group_policy.rb rule do ~knowledge_graph_namespace_eligible | ~knowledge_graph_enabled | ~knowledge_graph_saas_mode end.prevent :update_knowledge_graph_setting condition(:knowledge_graph_saas_mode, scope: :global) do ::Gitlab::Saas.feature_available?(:gitlab_com_subscriptions) end ``` On self-managed `knowledge_graph_saas_mode` is always `false`, so `~knowledge_graph_saas_mode` is always `true`, so the `prevent` always fires, for every user including instance admins and root. There is no `rule { admin }.enable :update_knowledge_graph_setting` anywhere in the policy tree. Because the GraphQL field `Group.knowledgeGraphAvailable` is `Ability.allowed?(current_user, :update_knowledge_graph_setting, object)` (`ee/app/graphql/ee/types/group_type.rb`), it returns `false` for every group on SM. That empties the dashboard's "configurable groups" list, so the "requires a Premium license" copy renders even when the instance has that license. The message is misleading. <details><summary>Where this surfaces across the UI</summary> | UI surface | Guard | File | |---|---|---| | `/dashboard/orbit` empty-state + "available" filter | GraphQL `knowledgeGraphAvailable` | `ee/app/graphql/ee/types/group_type.rb` | | Empty-state "no available groups" copy | `g.knowledgeGraphAvailable \|\| g.knowledgeGraphEnabled` | `ee/app/assets/javascripts/orbit/components/orbit_explore_empty_state.vue` | | `/admin/orbit` "Turn on indexing" buttons | `:disabled="!ns.knowledgeGraphAvailable"` | `ee/app/assets/javascripts/orbit/components/orbit_settings_page.vue` | | Group Settings → Orbit page | `can?(:update_knowledge_graph_setting, group)` | `ee/app/controllers/groups/settings/orbit_controller.rb` | | Group Settings → Orbit menu item | same | `ee/lib/ee/sidebars/groups/menus/settings_menu.rb` | | `OrbitUpdate` mutation → `ToggleNamespaceService` | `Ability.allowed?(:update_knowledge_graph_setting, group)` | `ee/app/services/analytics/knowledge_graph/toggle_namespace_service.rb` | The admin config path partially works: `admin_knowledge_graph_settings_available` (`ee/app/policies/ee/global_policy.rb`) does grant admins `:read_admin_knowledge_graph_settings` on SM when `License.feature_available?(:orbit) && Feature.enabled?(:knowledge_graph)`, so root reaches `/admin/orbit`, but the page still blocks enrollment on the SaaS-gated ability. </details> ## Proposal I think the fix is to make `:update_knowledge_graph_setting` satisfiable on self-managed for the users who should manage it (instance admins, and top-level group Owners), instead of hard-gating it to SaaS, parallel to how `:read_admin_knowledge_graph_settings` is already SM-aware. There's also an admin-scoped REST API that enrolls namespaces and is not tied to this ability (`PUT /admin/knowledge_graph/namespaces/:id`, `ee/lib/api/admin/knowledge_graph.rb`), so pointing the admin UI at that (or an admin-only mutation) is a lower-risk alternative that unblocks root without touching the group policy. One thing to confirm with the team: the exact enable-rule that grants `:update_knowledge_graph_setting` to owners today isn't obvious in-tree (only the `prevent` is referenced), so the intended owner-grant path should be nailed down before wiring the SM branch. We should also fix the empty-state copy so a licensed SM instance isn't told it lacks a Premium license it has. <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> ## Acceptance criteria - [ ] On a licensed SM instance with `knowledge_graph` enabled, root/admin can enroll a top-level group from the UI, creating an `EnabledNamespace` row without a console. - [ ] A top-level group Owner (non-admin) can enroll their own group from Group Settings → Orbit on SM, or this is explicitly deferred and the dead menu/button is removed. - [ ] The `/dashboard/orbit` empty state no longer claims "requires a Premium license" on an instance that has one. - [ ] Enrollment stays blocked for unlicensed instances and unprivileged users. - [ ] Policy specs cover: SM admin allowed, SM owner allowed (or deferred), SM non-owner/non-admin denied, SaaS unchanged, unlicensed denied.