Phase7: Void/Refund logic
All checks were successful
Build and Push / build (push) Successful in 1m42s
All checks were successful
Build and Push / build (push) Successful in 1m42s
This commit is contained in:
@@ -578,6 +578,36 @@ const MIGRATION_SQL = `
|
||||
CREATE INDEX IF NOT EXISTS idx_invoice_refunds_invoice
|
||||
ON invoice_refunds(invoice_id);
|
||||
|
||||
-- Phase 7 fix: the credit_notes.invoice_id and
|
||||
-- invoice_refunds.invoice_id FKs were originally created without
|
||||
-- ON DELETE CASCADE, which made admin "delete invoice" fail with
|
||||
-- a FK violation when the invoice had any voids/refunds attached.
|
||||
-- The production policy is to never delete an invoice that's been
|
||||
-- refunded (the credit notes are part of the customer's records),
|
||||
-- but the schema should allow the admin tool to clean up for test
|
||||
-- data. We drop and re-add the FKs with CASCADE so a delete tears
|
||||
-- down everything related. The DROP/ADD pair is idempotent — on a
|
||||
-- DB that already has the CASCADE variant it's a no-op (we drop
|
||||
-- by name and re-add identically).
|
||||
DO $cnfk$
|
||||
BEGIN
|
||||
ALTER TABLE credit_notes
|
||||
DROP CONSTRAINT IF EXISTS credit_notes_invoice_id_fkey;
|
||||
ALTER TABLE credit_notes
|
||||
ADD CONSTRAINT credit_notes_invoice_id_fkey
|
||||
FOREIGN KEY (invoice_id) REFERENCES invoices(id) ON DELETE CASCADE;
|
||||
END
|
||||
$cnfk$;
|
||||
DO $irfk$
|
||||
BEGIN
|
||||
ALTER TABLE invoice_refunds
|
||||
DROP CONSTRAINT IF EXISTS invoice_refunds_invoice_id_fkey;
|
||||
ALTER TABLE invoice_refunds
|
||||
ADD CONSTRAINT invoice_refunds_invoice_id_fkey
|
||||
FOREIGN KEY (invoice_id) REFERENCES invoices(id) ON DELETE CASCADE;
|
||||
END
|
||||
$irfk$;
|
||||
|
||||
-- Invoice line items. The kind column lets the PDF renderer
|
||||
-- group lines (all monthly fees together, all AI usage together,
|
||||
-- etc.) and the admin UI filter by category.
|
||||
|
||||
Reference in New Issue
Block a user