## Overview This issue tracks implementation planning for issue [#595666](https://gitlab.com/gitlab-org/gitlab/-/work_items/595666): **Admin-locked "Always off" Duo/DAP availability for selected subgroups**. The goal is to close the governance gap for GitLab customers who need to permanently disable Duo/DAP for specific subgroups while allowing other subgroups to remain owner-controllable under the same instance. --- ## Context Currently, GitLab supports an **Always Off** mode at the instance level, but it applies to the entire hierarchy. There is no way to selectively lock specific subgroups as **Always off (non-overrideable)** while leaving other sibling subgroups as **Off by default but owner-controllable**. This is a blocker for customers in regulated/public-sector environments who need: - A default-deny posture across the platform (instance = Off by default) - Hard-ban on Duo/DAP for specific agency subgroups (admin-locked Always off) - Owner-controlled opt-in for other subgroups --- ## Planning Tasks ### 1. Engineering Discovery - [ ] Audit the existing `Always Off` implementation to understand the enforcement cascade (instance → group → subgroup → project) - [ ] Identify all places in the codebase where Duo availability is read/evaluated and determine what changes are needed to support a new **admin-locked** `Always Off` state at the subgroup level - [ ] Assess how the new locked state interacts with the existing `Always Off` at instance level and parent group level - [ ] Confirm clean data migration path for all existing setting combinations - [ ] Identify API changes needed (REST and GraphQL) - [ ] Identify any frontend changes needed (admin UI, group settings, project settings) - [ ] Review relationship and shared implementation with [#594735](https://gitlab.com/gitlab-org/gitlab/-/work_items/594735) (Always on locked mode) for symmetry ### 2. Scope Definition - [ ] Confirm the exact scopes where admin-locked `Always Off` can be set (subgroup level, not just instance level) - [ ] Define who can apply/remove the locked state: instance admins only, or also root group Owners - [ ] Define the enforcement behavior: when admin-locked `Always Off` is set, subgroup/project owners cannot enable Duo within that scope - [ ] Clarify interaction with the DAP Control Plane and child capability toggles - [ ] Define behavior when instance is `Off by default` and a subgroup is `Always off (locked)` — confirm no conflict - [ ] Define clear messaging shown to subgroup/project Owners when Duo is locked by an ancestor admin ### 3. Design & UX - [ ] Align with UX on UI changes for the admin panel and group settings page - [ ] Review copy/legal implications (e.g., labeling and descriptions for the new locked mode) - [ ] Design the visual distinction between owner-set `Always Off` and admin-locked `Always Off` - [ ] Consider the broader AI Section proposal (two-control redesign) and whether any parts should be incorporated now or deferred ### 4. Testing Strategy - [ ] Define unit and integration test coverage for the new enforcement logic - [ ] Plan E2E test scenarios covering: - Instance `Off by default` + subgroup `Always off (locked)` + sibling subgroup `Off by default (owner-controllable)` - Admin applying and removing the locked state - Owner attempting to override the locked state (should be blocked) - [ ] Identify edge cases: mixed settings across nested groups, migration from existing states ### 5. Rollout & Migration - [ ] Define feature flag strategy - [ ] Confirm no data loss for existing setting combinations - [ ] Plan documentation updates --- ## Open Questions - [ ] Should admin-locked `Always Off` be available only on GitLab, or also on self-managed and GitLab.com? - [ ] What is the interaction between admin-locked `Always Off` at subgroup level and a parent group that has `Always Off` (non-locked) set? Which takes precedence? - [ ] Can a root group Owner apply the locked state, or is it instance-admin-only? - [ ] Engineering confirmation of clean data migration for all existing setting combinations - [ ] How does this interact with the related `Always On (locked)` work in [#594735](https://gitlab.com/gitlab-org/gitlab/-/work_items/594735)? Should they share implementation? --- ## Requirements / Product Decisions - The locked `Always Off` state must be **settable and removable only by instance administrators** (not subgroup/project Owners). - Subgroup/project Owners must see **clear messaging** that Duo is disabled and locked by an ancestor admin. - The feature must support a **mixed model** under the same instance: some subgroups locked Always off, others Off by default but owner-controllable. --- ## References - Parent Issue: [#595666](https://gitlab.com/gitlab-org/gitlab/-/work_items/595666) Admin-locked "Always off" Duo/DAP availability for selected subgroups on GitLab - Related Issue: [#594735](https://gitlab.com/gitlab-org/gitlab/-/work_items/594735) Add 'Always on' GitLab Duo availability mode that group Owners cannot override - Planning template reference: [#598361](https://gitlab.com/gitlab-org/gitlab/-/work_items/598361) Implementation Planning: Add 'Always On' availability mode for Duo