Skip to main content

case_status enum history

The Postgres case_status enum evolved through three migrations and, because PG enums cannot drop values, all of them are still legal states in the column.

  • v1 (20260212…): new, in_progress, under_review, closed
  • v2 (20260228115614, destructive DROP+CREATE with a data remap new→DRAFT / in_progress→INTAKE / under_review→EVIDENCE_PHASE / closed→CLOSED): DRAFT, INTAKE, PRELIMINARY_INQUIRY, FORMAL_PROCEEDING, CHARGES_NOTICE, EMPLOYEE_RESPONSE, EVIDENCE_PHASE, DECISION_DRAFT, DECISION_ISSUED, CLOSED, SUSPENDED, CANCELLED
  • v3 (20260228140501, ADD VALUE ×11): FORMAL_OPEN, PREPARE_CHARGES, CHARGES_REVIEW, CHARGES_ISSUED, CONSULTATION_PORTAL, RESPONSE_WINDOW, BODIES_CHECK, BODIES_OPINION, FINAL_REPORT, DECISION_REVIEW, ARCHIVED

Column default is 'DRAFT'.

The app's CaseStatus type (workflow-config.ts) recognises only 8 operational + 3 terminal of these ~24. The frontend also uses DRAFT and CANCELLED in raw queries (via as any) even though they're absent from CaseStatus, and seed-test-data writes yet another subset (FORMAL_PROCEEDING, CHARGES_NOTICE). See the fuller analysis in three status generations.

Rebuild implication​

Pick one canonical status set, write an explicit legacy→canonical mapping covering all ~24 values (including v1 lowercase and the v2 orphans FORMAL_PROCEEDING, CHARGES_NOTICE, EMPLOYEE_RESPONSE, DECISION_*), and migrate the column with a CHECKed conversion. Decide what DRAFT/CANCELLED map to.