MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-87

2.3.2 E2E — delete-with-reassign flow end-to-end (Playwright)

Done
Description

Estimate: 12m · Depends on: 2.3.1

Playwright suite that exercises 2.3.1's delete-with-reassign flow against the real stack — the settings page, the Server Action, the service transaction, the revisions pipeline, and the post-mutation revalidate are all on the wire. Lives at tests/e2e/workflow-delete-reassign.spec.ts beside the existing workflow-flow suite from Story 2.2's 2.2.7.

Why this is a separate Subtask, not folded into 2.3.1's AC: the Vitest in 2.3.1 hits the service layer with real Postgres; the E2E proves the UI + Server Action + revalidation seams. Different infra, different failure modes — one shouldn't gate the other in the PR queue. The two-card split also lets the E2E iterate independently (selectors, flakiness fixes) without re-opening the service-layer Subtask.

Deliberately decoupled from 2.3.3. This spec must NOT use Story 2.3's new create-issue modal (2.3.3) or edit form (2.3.6) for issue setup — the existing tests/e2e/_helpers/workflow.ts from 2.2.7 already drives work-item creation + status changes through the /api/_test/work-items harness route (which calls the gated service methods directly). Reusing that harness means 2.3.2 has NO ordering dependency on 2.3.3, so the two parallel halves of Story 2.3 (delete-with-reassign vs. create/edit form) can dispatch and merge independently. This mirrors how 2.2.7 itself worked around the not-yet-shipped issue detail page.

Scenario (single happy-path spec, three assertions):

  • Setup (all via the 2.2.7 _test harness): sign in as a project admin; create a project (default workflow seeds itself per 2.2.2); use the workflow settings UI to add a custom status 'triage' (this is part of the delete-with-reassign feature under test — 2.2.5's UI, NOT 2.3.3); create N=3 work items via createItem(helpers, {status: 'triage'}) from _helpers/workflow.ts (the harness POST accepts an initial status, gated through workItemsService.createWorkItem + updateStatus).
  • Act: navigate to /settings/project/[key]/workflow, click delete on the triage status row, the reassign modal opens showing "3 issues use this status — move them to:", pick todo, confirm.
  • Assert: (1) toast confirms success; (2) the triage row disappears from the editor; (3) for each of the 3 work items, a service-layer read via the _test harness GET (NOT the not-yet-shipped detail page, NOT 2.3.6's edit form) confirms status: 'todo' AND the revisions table contains one status-change row per item with from: triage, to: todo.

Negative path (second spec): attempt to delete the initial status (e.g. todo) with a target supplied — the reassign modal's confirm button is disabled OR (if it's clickable) the toast surfaces CANNOT_DELETE_INITIAL_STATUS, the status row remains. Proves 2.3.1's protection still fires through the UI seam.

Acceptance criteria

  • pnpm test:e2e --grep workflow-delete-reassign passes locally and in CI against a fresh-DB Playwright run.
  • Happy-path spec asserts all three observations above (toast + editor row gone + per-item status + per-item revision).
  • Negative-path spec asserts the initial-status protection is honored through the UI.
  • Uses only the auth + 2.2.7 _test harness helpers (tests/e2e/_helpers/workflow.ts · createItem / transition) to set up issues — does NOT import or drive 2.3.3's create modal, 2.3.6's edit form, or any future issue detail page. This keeps 2.3.2's depends_on at [2.3.1] only; no cross-flow ordering with the create/edit half of the Story.
  • If createItem needs a new option (e.g. accept {initialStatus} to drop the issue straight into the custom status without a follow-up transition call), extend the existing helper — do NOT add a parallel one.
  • Selectors target stable data-testid hooks added in 2.3.1 (if any are missing, add them in this Subtask under the 2.3.1 components — do NOT add brittle text/role-only selectors).
  • No flake under 10 consecutive runs in CI mode.

Context refs

  • tests/e2e/workflow-flow.spec.ts + tests/e2e/_helpers/workflow.ts (Story 2.2's 2.2.7) — the existing E2E + helper this spec sits beside and consumes; createItem / transition already exist and drive the gated service methods via /api/_test/work-items
  • tests/e2e/_helpers/shell-session.ts (1.5.6) — sign-in + createWorkspace + createProject helpers
  • app/(authed)/settings/project/workflow/_components/WorkflowEditor.tsx + reassign modal from 2.3.1 — the components the spec drives
  • app/api/_test/work-items/route.ts — the harness route 2.2.7 extended; check its GET surface (or extend it) for the per-item assertions; do NOT reach for 2.3.6's edit form or any not-yet-shipped detail page
  • Playwright config + CI matrix from playwright.config.ts