feat(web): wire the delete-application admin UI (BUNYIP-65) #83

Merged

nrupard merged 2 commits from feat/bunyip-65-delete-applications into main

2026-06-09 20:13:47 +02:00

nrupard commented

2026-06-09 20:07:17 +02:00

Owner

Problem

bunyip-api already exposed DELETE /admin/applications/{id} (admin-only, gated on the admin's password + 2FA code, all foreign keys cascade, audit-logged via ApplicationDeleted), but no part of bunyip-web reached it. Admins could create and edit applications but never delete one.

Fix

This is purely the missing web wiring; no API or schema change.

admin_api::delete_application posts the credentials as the DELETE JSON body the API expects ({ password, totp_code }).
A Danger Zone on the application edit page (application_edit) mirrors the account self-delete UI: it collects the admin's password and 2FA code, confirms via a native dialog, and posts to the new route.
POST /admin/applications/{id}/delete (application_delete): on success returns to /admin/applications; on failure (bad password or 2FA code) it bounces back to the edit page's danger zone with the API's validation message via an ?error= query param, so the admin sees why rather than landing on a blank page.

Notes

Delete lives on the edit page (not the list) so the credential prompt has room and matches where other per-app mutations already live.
The form uses POST (not a raw DELETE verb) for plain-HTML form compatibility, matching the existing user-delete pattern.

Test

just check-container green: fmt + clippy (-D warnings) + workspace lib tests all pass.

#BUNYIP-65

## Problem bunyip-api already exposed `DELETE /admin/applications/{id}` (admin-only, gated on the admin's password + 2FA code, all foreign keys cascade, audit-logged via `ApplicationDeleted`), but no part of bunyip-web reached it. Admins could create and edit applications but never delete one. ## Fix This is purely the missing web wiring; no API or schema change. - `admin_api::delete_application` posts the credentials as the DELETE JSON body the API expects (`{ password, totp_code }`). - A Danger Zone on the application edit page (`application_edit`) mirrors the account self-delete UI: it collects the admin's password and 2FA code, confirms via a native dialog, and posts to the new route. - `POST /admin/applications/{id}/delete` (`application_delete`): on success returns to `/admin/applications`; on failure (bad password or 2FA code) it bounces back to the edit page's danger zone with the API's validation message via an `?error=` query param, so the admin sees why rather than landing on a blank page. ## Notes - Delete lives on the edit page (not the list) so the credential prompt has room and matches where other per-app mutations already live. - The form uses POST (not a raw DELETE verb) for plain-HTML form compatibility, matching the existing user-delete pattern. ## Test `just check-container` green: fmt + clippy (`-D warnings`) + workspace lib tests all pass. #BUNYIP-65

nrupard added 1 commit

2026-06-09 20:07:17 +02:00

feat(web): wire the delete-application admin UI (BUNYIP-65)

Check / fmt / clippy / build / test (pull_request) Successful in 1m11s

Details

2d34eb5021

The API already exposed `DELETE /admin/applications/{id}` (admin-only, gated on the admin's password + 2FA code, FKs cascade, audit-logged) but nothing in bunyip-web reached it, so applications could be created and edited but never removed.

Add a Danger Zone to the application edit page that mirrors the account self-delete: it collects the admin's password and 2FA code, confirms via a native dialog, and posts to a new `POST /admin/applications/{id}/delete` route. The handler calls the API with both credentials; on success it returns to the applications list, and on failure (bad password or 2FA code) it bounces back to the edit page's danger zone with the API's validation message via an `?error=` param.

`admin_api::delete_application` sends the credentials as the DELETE JSON body the API expects. No API or schema changes: this is purely the missing web wiring.

#BUNYIP-65

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nrupard added 1 commit

2026-06-09 20:11:22 +02:00

fix(web): relay rotated session cookie on delete-application redirect (BUNYIP-65)

Check / fmt / clippy / build / test (pull_request) Successful in 1m28s

Details

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

Details

2514e928d0

Code-review follow-up. The delete handler used a plain `redirect()` on both the success and error paths, dropping any session cookie the admin guard rotated during the request. If the guard refreshed the session, the admin would be silently logged out. Use `redirect_cookies(&c.set_cookies)` on both arms, matching the canonical user_delete handler.

#BUNYIP-65

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>