feat(ui): surface Delete on Project/Asset and Invoice lifecycle actions #144

Merged

David merged 1 commit from feat/mapps-158-detail-page-actions into main

2026-06-14 18:43:36 +02:00

David commented

2026-06-14 18:26:59 +02:00

Owner

Project and Asset detail pages now expose a Delete action in the page header, wired to the existing DELETE /projects/{id} and DELETE /assets/{id} endpoints with the same confirm-then-navigate pattern Company and Contract already use, closing the parity gap where those entities could be created and edited but never deleted from the UI.

The Invoice detail page gains its lifecycle actions, each wired only to a backing endpoint so no unwired controls are introduced (cf. MAPPS-102): Edit (header fields via PUT /invoices/{id}), Send and Void (status transitions via the same PUT), and Record Payment (the existing modal seeded with the invoice's company and id, posting to /payments). Edit/Send/Void are surfaced only while the invoice is editable (draft/pending), because the backend freezes writes once an invoice leaves those states (InvoiceStatus::is_frozen); Record Payment shows whenever a balance can still be collected.

Actions with no backend route (delete/un-send/email an invoice) and line-item editing (which requires a credit note) are intentionally omitted and documented inline as remaining work.

#MAPPS-158

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

Project and Asset detail pages now expose a Delete action in the page header, wired to the existing `DELETE /projects/{id}` and `DELETE /assets/{id}` endpoints with the same confirm-then-navigate pattern Company and Contract already use, closing the parity gap where those entities could be created and edited but never deleted from the UI. The Invoice detail page gains its lifecycle actions, each wired only to a backing endpoint so no unwired controls are introduced (cf. MAPPS-102): Edit (header fields via `PUT /invoices/{id}`), Send and Void (status transitions via the same PUT), and Record Payment (the existing modal seeded with the invoice's company and id, posting to `/payments`). Edit/Send/Void are surfaced only while the invoice is editable (draft/pending), because the backend freezes writes once an invoice leaves those states (`InvoiceStatus::is_frozen`); Record Payment shows whenever a balance can still be collected. Actions with no backend route (delete/un-send/email an invoice) and line-item editing (which requires a credit note) are intentionally omitted and documented inline as remaining work. #MAPPS-158 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

David added 1 commit

2026-06-14 18:26:59 +02:00

feat(ui): surface Delete on Project/Asset and Invoice lifecycle actions

Check / clippy + fmt + tests (pull_request) Successful in 51s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

32fd828b39

Project and Asset detail pages now expose a Delete action in the page header, wired to the existing `DELETE /projects/{id}` and `DELETE /assets/{id}` endpoints with the same confirm-then-navigate pattern Company and Contract already use, closing the parity gap where those entities could be created and edited but never deleted from the UI.

The Invoice detail page gains its lifecycle actions, each wired only to a backing endpoint so no unwired controls are introduced (cf. MAPPS-102): Edit (header fields via `PUT /invoices/{id}`), Send and Void (status transitions via the same PUT), and Record Payment (the existing modal seeded with the invoice's company and id, posting to `/payments`). Edit/Send/Void are surfaced only while the invoice is editable (draft/pending), because the backend freezes writes once an invoice leaves those states (`InvoiceStatus::is_frozen`); Record Payment shows whenever a balance can still be collected.

Actions with no backend route (delete/un-send/email an invoice) and line-item editing (which requires a credit note) are intentionally omitted and documented inline as remaining work.

#MAPPS-158

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>