<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=593900) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=593900) </details> <!--IssueSummary end--> ## Overview This issue covers the end-to-end design for the "Enable scanner" wizard and its surrounding context on the group-level Security Configuration page. The wizard is the primary mechanism through which security owners enable scanners across their project portfolio — making it a critical interaction surface, supporting Configuration Profiles. The scope of this issue is intentionally broader than the wizard steps alone. The entry point (group-level Scanners tab) and the group-level visibility model are inseparable from the wizard: they establish the context that makes the wizard meaningful, and they reflect the outcome of completing it. Designing these together ensures that the full centralized enablement loop is coherent. --- ## Problem Statement Security and platform teams at large Ultimate customers need to enable security scanners across hundreds or thousands of projects — safely, consistently, and without requiring individual CI changes per project. Today there is no guided, centralized path for doing this. Enablement is manual, fragmented, and carries real risk of pipeline breakage, cost surprises, and configuration drift. This issue addresses the design of the primary onboarding flow for Configuration Profiles: the surface where security owners go to get started, the wizard that guides them through setup, and the group-level view that confirms the outcome. --- ## Goals 1. Design a guided wizard that lets security owners enable one or more scanners across a defined set of projects with minimal friction and high confidence. 2. Establish the group-level Security Configuration page (Scanners tab) as the canonical entry point for centralized scanner enablement — not a secondary or supplementary surface. 3. Ensure the group-level Scanners tab provides enough visibility (coverage, health, profiles in use) that users can confidently initiate the wizard knowing what already exists and what gaps remain. 4. Design for both the Quick Setup path (recommended defaults, minimal decisions) and the Advanced Setup path (fine-grained control), ensuring the paths are clearly differentiated without making the Quick path feel limited. 5. Design all wizard steps end-to-end, including the Review step and post-wizard outcome states — success, partial failure, and error — which are currently absent from in-progress designs. --- ## Alignment to Epic | Epic Strategic Direction | How This Issue Contributes | |--------------------------|----------------------------| | Make centralized enablement the default entry point | The wizard, launched from the group Security Configuration page, is the primary path for enabling scanners at scale. This issue designs that entry point and flow as a first-class, recommended experience. | | Ensure enablement is safe and predictable at enterprise scale | The Review step and post-wizard states are critical to building confidence at scale. Users need to see exactly what will change before confirming, and understand the outcome clearly afterward. | | Provide clear, shared understanding of "what is enabled where, and why" | The group-level Scanners tab surfaces scanner coverage, health, and profiles in use across the group — giving security owners the context they need before and after running the wizard. | | Measure adoption and value from centralized enablement | Wizard completion is a primary instrumentation point. Design must support clear success states that tie back to coverage outcomes visible on the group page. | --- ## Scope ### In scope - **Group Security Configuration page — Scanners tab:** Entry point design, including scanner table, stat cards, and "Enable scanner" CTA. All relevant states: empty (no scanners enabled), partial (some enabled), healthy, and with warnings. - **Wizard: Approach selection step** — Quick Setup vs. Advanced Setup paths. Finalization and refinement of in-progress designs. - **Wizard: Scope selection step** — Project selection experience. MVC ships with manual selection only; rule-based selection is deferred but the design should not foreclose it. - **Wizard: Scanner selection and profile assignment step** — Scanner cards, profile dropdown, and handling of the case where a scanner is already enabled for some projects in the selected scope. - **Wizard: Review step** — Not yet designed. Summary of scope, scanners selected, and profiles to be applied. This is the last confirmation before changes are committed. - **Wizard: Post-wizard outcome states** — Success (all projects updated), partial failure (some projects failed), and error states. Includes the transition back to the group Scanners tab with updated coverage reflecting the completed rollout. - **Wizard: Step indicator and navigation patterns** — Progress stepper, back/cancel behavior, and handling of unsaved state. ### Out of scope - Rule-based scope selection (deferred from MVC; design should leave room for it but not design it) - Custom/user-configurable profiles (deferred from Phase One entirely) --- ## Open Questions 1. **Partial scope overlap on scanner selection:** If a user selects projects where some already have a scanner profile applied, how does the wizard communicate this? Options: warn on the scanner selection step, surface it in Review, or handle silently. 2. **See also:** [Open questions: Centralized scanner enablement (Google doc)](https://docs.google.com/document/d/12-UHjhTz8Gl5LZuQ9E3rFvIIKIBP9SbfhTQRFXkONS8/edit?usp=sharing) --- ## Design Decisions Decisions made during the design process, preserved for reference. **Quick Setup path — does it skip scope and scanner selection?**\ Pre-selects all projects and all scanners with default profiles, skipping Steps 2 and 3 and landing the user directly on the Review step. Steps 2 and 3 appear as pre-completed in the step indicator and remain accessible via navigation. **Review step content depth**\ High-level summary — paginated project list, scanners selected with profile per scanner, Estimated CI impact section, and Rollout plan section. Per-project detail is not shown inline. **Wizard entry from scanner detail page ("Enable for projects without coverage")**\ Sends users directly to the Review step, pre-populated with unconfigured projects and the current scanner already selected. Steps 2 and 3 are skipped since the user is already in the context of a specific scanner. **Post-wizard status and rollout monitoring**\ Email notification only for the crawl phase. Both the Review step (Rollout plan section) and Setup Complete page include: _"You will receive an email summary when the rollout completes."_ No in-UI status banner for crawl. The Security Inventory serves as the durable reference for operation history. **Rule-based scope selection**\ Absent from MVC entirely — no placeholder or structural affordance. Will be introduced as a follow-on iteration. --- ## Acceptance Criteria - [x] Complete screen designs exist for all wizard steps across both Quick Setup and Advanced Setup paths _(success path only — failure states still needed)_ - [x] Entry point on the group Security Configuration page is fully designed, including the empty/first-run state - [x] Review step designed and specced - [ ] Post-wizard outcome states designed: success ✓, partial failure ✗, full failure ✗ - [x] All designs reviewed against the "one pattern, all profiles" constraint - [x] Open questions above resolved or explicitly deferred with rationale _(one unresolved: partial scope overlap on scanner selection)_