fix(room): restore the delete-room affordance on the room info page (LC-400) #418

Merged

longjacksonle merged 1 commit from fix/lc-400-room-delete-ui into main

2026-06-21 00:01:01 +02:00

longjacksonle commented

2026-06-21 00:00:41 +02:00

Owner

Bug

An enclave owner could not delete a room: there was no UI for it anywhere in the normal app. The LC-336 redesign removed the enclave landing menu (which hosted room management), orphaning the /enclave/{id}/rooms/{room_id}/delete route - the handler still existed and the RBAC gate still passed for an owner, but nothing in any template POSTed to it. Only the separate site-admin panel had a room-delete action.

Fix

Restore the affordance on the room's own info page (/room/{id}/info, docs tab):

New "Danger zone" section with a "Delete room" button, gated by can_manage = enclave_can_manage(role, site_role) - the exact role post_delete_room enforces (enclave owner/admin or site admin). Hidden for everyone else and for DMs / rooms with no enclave.
The info handler already resolves the room's enclave and the viewer's enclave role for the wiki/description gates; this reads that role once and derives both can_manage_overrides and the new can_manage, and passes enclave_id so the form can target /enclave/{enclave_id}/rooms/{room_id}/delete.
Native POST with a JS confirm; the handler's existing redirect (out of the now-deleted room back into the enclave) runs as a full navigation. New i18n keys in en + es room.ftl.

Scope

room_info.rs (compute + pass two fields), views/room_info.rs (two struct fields), templates/room/info.html (the section), locales/{en,es}/room.ftl (3 keys each). No route, schema, or RBAC change - the handler and its gate are untouched.

Note

Room rename / topic edit (/enclave/{id}/rooms/{room_id}/edit) and per-room member management were orphaned by the same redesign commit and are still unreachable from the UI. Out of scope here (the report was specifically about delete); happy to restore those next.

Tests

just check (standalone + saas compile, clippy, fmt), just test, and just test-saas all pass. just build-css regenerated.

## Bug An enclave owner could not delete a room: there was no UI for it anywhere in the normal app. The LC-336 redesign removed the enclave landing menu (which hosted room management), orphaning the `/enclave/{id}/rooms/{room_id}/delete` route - the handler still existed and the RBAC gate still passed for an owner, but nothing in any template POSTed to it. Only the separate site-admin panel had a room-delete action. ## Fix Restore the affordance on the room's own info page (`/room/{id}/info`, docs tab): - New "Danger zone" section with a "Delete room" button, gated by `can_manage` = `enclave_can_manage(role, site_role)` - the exact role `post_delete_room` enforces (enclave owner/admin or site admin). Hidden for everyone else and for DMs / rooms with no enclave. - The info handler already resolves the room's enclave and the viewer's enclave role for the wiki/description gates; this reads that role once and derives both `can_manage_overrides` and the new `can_manage`, and passes `enclave_id` so the form can target `/enclave/{enclave_id}/rooms/{room_id}/delete`. - Native POST with a JS confirm; the handler's existing redirect (out of the now-deleted room back into the enclave) runs as a full navigation. New i18n keys in `en` + `es` room.ftl. ## Scope `room_info.rs` (compute + pass two fields), `views/room_info.rs` (two struct fields), `templates/room/info.html` (the section), `locales/{en,es}/room.ftl` (3 keys each). No route, schema, or RBAC change - the handler and its gate are untouched. ## Note Room rename / topic edit (`/enclave/{id}/rooms/{room_id}/edit`) and per-room member management were orphaned by the same redesign commit and are still unreachable from the UI. Out of scope here (the report was specifically about delete); happy to restore those next. ## Tests `just check` (standalone + saas compile, clippy, fmt), `just test`, and `just test-saas` all pass. `just build-css` regenerated.

longjacksonle added 1 commit

2026-06-21 00:00:41 +02:00

fix(room): restore the delete-room affordance on the room info page (LC-400)

check-secrets / TruffleHog (push) Successful in 4s

Details

check-secrets / Nosey parker (push) Successful in 4s

Details

check-secrets / Kingfisher (push) Successful in 5s

Details

check-secrets / Nosey parker (pull_request) Successful in 3s

Details

check-secrets / Kingfisher (pull_request) Successful in 6s

Details

check-secrets / TruffleHog (pull_request) Successful in 6s

Details

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

Details

Check / clippy + fmt + tests (pull_request) Successful in 4m13s

Details

6eeadff1bc

The LC-336 redesign removed the enclave landing menu, which hosted room management - including the only UI that POSTed to /enclave/{id}/rooms/{room_id}/delete. The route and handler survived but became orphaned, so an enclave owner had no way to delete a room from the normal UI (only the separate site-admin panel could).

Add a "Delete room" action to the room's own info page (/room/{id}/info, docs tab), gated by `enclave_can_manage` - the exact role post_delete_room already enforces (enclave owner/admin or site admin). The info page already resolves the room's enclave and the viewer's enclave role for the wiki/description gates, so this reuses that role lookup (now read once) and adds a `can_manage` flag plus the room's `enclave_id` to RoomInfoPage.

Native POST with a JS confirm; the handler's redirect (out of the now-deleted room into the enclave) runs as a full navigation. New i18n keys in en + es room.ftl.

Frontend + thin handler wiring; no route, schema, or RBAC change. just check, just test, just test-saas all pass.

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