## Summary Second of three backend MRs for status on Epics. This one **enables status on the Epic type behind a feature flag**: adds the widget and the base type, gates it per type, and adds the read-time mask plus persist-on-write so epics resolve status correctly in both system-defined and custom-lifecycle namespaces. Depends on the lifecycle provider from MR 1. Part of the [Status on epics POC](https://gitlab.com/gitlab-org/gitlab/-/work_items/605494). Related to https://gitlab.com/groups/gitlab-org/-/work_items/17709. ## Background Status currently ships on Issue and Task, both project-level. Epics are group-level, but lifecycle resolution is already keyed on the root ancestor, so group scoping is not the hard part. Two namespace situations: - **System-defined-lifecycle namespaces (the default):** trivial. Add `:epic` to the system lifecycle base types and expose the widget, and epics resolve immediately. - **Custom-lifecycle namespaces:** custom lifecycles were only ever seeded with Issue + Task rows. An epic there has no connection, so it resolves nothing and silently falls back to system statuses while issues/tasks use custom statuses. That divergence breaks the "a namespace uses either system or custom" invariant. The fix is a **read-time mask**: a status-supporting type with no direct connection resolves to the Issue lifecycle (or the first available). Reads are correct from day one, epic mirrors Issue, no divergence, no backfill. The mask is type-agnostic; it keys on "does this type have the status widget", not on "is this an epic". ## Scope Build on `WorkItems::Statuses::Lifecycles::Provider` (MR 1): - **Add `:epic` to `work_item_base_types`** in `ee/app/models/work_items/statuses/system_defined/lifecycle.rb`. - **Add the `status` widget** to the Epic definition `ee/app/models/work_items/types_framework/system_defined/definitions/epic.rb` (alphabetical in the widget array). - **Feature flag** `work_item_status_for_epics` (type `wip`, `group::project management`, `default_enabled: false`, root-ancestor scoped). New file under `config/feature_flags/wip/`. - **Widget-reject gate** in EE `SystemDefined::Type#widgets`: reject the `status` widget when the flag is off for the type's root ancestor. Use a single `widget_excluded?` predicate (avoids `Style/MultilineBlockChain`) with a per-type `status_feature_flag_disabled?` case: an `epic` branch live, a commented `ticket` placeholder for the secondary goal. - **The mask in the provider:** `find_custom_by_type` returns `index[persistable_id] || masked_lifecycle` where `masked_lifecycle` = the Issue type's lifecycle (or the first available). Gate both the custom path and the system-defined fallback with `type_supports_status?` (widget present), so a widget-off / flag-off type resolves nil everywhere (fully dormant). - **Widget-aware `supports_status?`** in `ee/app/models/concerns/ee/issuable.rb`: check `work_item_type.widgets(resource_parent)` includes the status widget. Widget presence already encodes the license and the flag, so this single check gates the webhook / hook-data capability sites consistently. (Verified cheap: widget definitions are in-memory FixedItems, license/flag checks are request-memoized, so no per-item query.) - **Persist-on-write:** the first time status is written to a masked epic (`WorkItems::Widgets::Statuses::UpdateService`), materialize the real `work_item_type_custom_lifecycles` row via a provider `ensure_connection!` before the `CurrentStatus` validation runs. Idempotent, rescue `ActiveRecord::RecordNotUnique`. Reset the current_status association after creating the row (an unsaved current_status may have been built earlier in the request via `status_with_fallback` while the type was masked, memoizing the wrong state). ## Important details / gotchas (from the POC) - **Stale current_status bug:** in the full update path, `status_with_fallback` (webhook change detection) builds an unsaved current_status while the epic is still masked, memoizing `custom_status_enabled? = false` with a system default. The widget update then reused it and rejected the custom status. Fix: `ensure_connection!` returns whether it created a row; when it did and the current_status is not persisted yet, reset the association so the write builds fresh. This is validated in the POC and is the tricky part. - **Gate composition:** the provider mask, the `TypeCustomLifecycle` widget validation, and `supports_status?` all ask the same "does this type have the status widget" question, so flag-off cascades cleanly to fully dormant. - **Airtightness gap to close here:** `SystemDefined::Status#allowed_for_work_item?` reads `work_item_base_types` directly, bypassing the flag gate, so with the flag off a system status is still "allowed" for epic at the validation layer (it does not leak a resolved lifecycle, the provider gates that, but it is an inconsistency). Make `allowed_for_work_item?` flag/widget-aware so flag-off is 100% dormant. This is the fix for the deferred `current_status_spec` "epic statusless -> invalid" failure. ## Out of scope (later MRs) - Lifecycle-mutation handling (removing a status, reassigning the Issue type, delete protection) - that is MR 3. - The `Custom::Lifecycle#work_item_types` masked projection and mapping generation - MR 3. - Ticket status (secondary goal) - only the commented placeholder in the gate. ## Acceptance criteria - [ ] With the flag ON: epics resolve status in list + detail; set/change status; close/reopen via status; create with explicit and default status; filter and sort by status; subgroup epics; "manage statuses" link routes to the root group. - [ ] With the flag ON in a custom-lifecycle namespace: epic resolves the SAME custom lifecycle as Issue (no divergence); the status filter shows only the custom statuses; setting a custom status persists the connection with no validation error. - [ ] With the flag OFF: the epic status widget is absent; the provider resolves nil for epic; issues/tasks are unaffected; no epic status in webhook payloads; `supports_status?` is false for epics. - [ ] `allowed_for_work_item?` respects the flag (flag-off = fully dormant at the validation layer). - [ ] Specs cover flag on/off for the widget gate, the mask (custom-hit + fallback), persist-on-write (including the stale-association case), and `supports_status?`. ## Verification - `bundle exec rspec` on the affected model/service specs (provider, EE type, current_status, widgets/statuses update service, issuable) with the flag stubbed both ways. - `bundle exec rubocop` on changed files. - Manual: enable `work_item_status_for_epics` for a group, exercise the acceptance criteria on both a system-defined and a custom-lifecycle group.