feat(realtime): live enclave settings-page member list (LC-172) #217

Merged
nrupard merged 1 commit from feat/lc-172-live-settings-members into main 2026-05-26 18:00:24 +02:00
Owner

Closes LC-172. Continuation of LC-170 (live enclave landing member/room lists). The enclave settings page (/enclave/{id}/settings) renders its own member list carrying the kick / role-toggle / transfer controls and is where managers actually work, but it did not subscribe to the enclave topic, so it stayed static until reload. LC-170 already broadcasts EnclaveMember{Added,Removed,RoleChanged} on the enclave:{id} topic; this wires the settings page as a second consumer.

Changes

  • The settings member list is extracted into a shared partial (enclave/settings_members_items.html) so the page and the live OOB fragment (ws/enclave_settings_members_live.html, swapping #lc-enclave-settings-members) render identically. The other settings sections (visibility, invite code, emojis, groups, branding, delete) are untouched.
  • The settings page now carries data-lc-live-topic="enclave:{id}". topic_subscribe_allowed already authorizes enclave members and (from the LC-170 review) site admins; get_settings already 403s non-managers, so only managers reach the page.
  • render_enclave_members now takes the recipient and emits BOTH member fragments in one frame: the read-only landing list (#lc-enclave-members, recipient-independent) and the settings list (#lc-enclave-settings-members, rendered per recipient because the kick/role/transfer controls gate on can_delete). A connection on the landing page matches only the first id, a connection on settings only the second, and htmx silently drops the unmatched OOB target. The enclave row is fetched once for the settings variant; if it is gone the landing fragment is the sole output.

Out of scope

The User groups section on the settings page has no broadcast events today (group CRUD fires nothing over the WS), so live group updates are deferred rather than wired here.

Verification

just test and just test-saas both green (106 test result: ok each, zero failures); cargo clippy / cargo fmt clean. New regression test (routes_enclave_nav::settings_page_is_wired_for_live_member_updates) asserts the settings page subscribes to the topic, renders the swappable member region, and still shows the manager controls inside it.

Closes LC-172. Continuation of LC-170 (live enclave landing member/room lists). The enclave settings page (`/enclave/{id}/settings`) renders its own member list carrying the kick / role-toggle / transfer controls and is where managers actually work, but it did not subscribe to the enclave topic, so it stayed static until reload. LC-170 already broadcasts `EnclaveMember{Added,Removed,RoleChanged}` on the `enclave:{id}` topic; this wires the settings page as a second consumer. ## Changes - The settings member list is extracted into a shared partial (`enclave/settings_members_items.html`) so the page and the live OOB fragment (`ws/enclave_settings_members_live.html`, swapping `#lc-enclave-settings-members`) render identically. The other settings sections (visibility, invite code, emojis, groups, branding, delete) are untouched. - The settings page now carries `data-lc-live-topic="enclave:{id}"`. `topic_subscribe_allowed` already authorizes enclave members and (from the LC-170 review) site admins; `get_settings` already 403s non-managers, so only managers reach the page. - `render_enclave_members` now takes the recipient and emits BOTH member fragments in one frame: the read-only landing list (`#lc-enclave-members`, recipient-independent) and the settings list (`#lc-enclave-settings-members`, rendered per recipient because the kick/role/transfer controls gate on `can_delete`). A connection on the landing page matches only the first id, a connection on settings only the second, and htmx silently drops the unmatched OOB target. The enclave row is fetched once for the settings variant; if it is gone the landing fragment is the sole output. ## Out of scope The User groups section on the settings page has no broadcast events today (group CRUD fires nothing over the WS), so live group updates are deferred rather than wired here. ## Verification `just test` and `just test-saas` both green (106 `test result: ok` each, zero failures); `cargo clippy` / `cargo fmt` clean. New regression test (`routes_enclave_nav::settings_page_is_wired_for_live_member_updates`) asserts the settings page subscribes to the topic, renders the swappable member region, and still shows the manager controls inside it.
feat(realtime): live enclave settings-page member list (LC-172)
All checks were successful
check-secrets / Nosey parker (push) Successful in 3s
check-secrets / TruffleHog (push) Successful in 4s
check-secrets / Kingfisher (push) Successful in 5s
check-secrets / Kingfisher (pull_request) Successful in 4s
check-secrets / Nosey parker (pull_request) Successful in 4s
check-secrets / TruffleHog (pull_request) Successful in 5s
Check / clippy + fmt + tests (pull_request) Successful in 1m29s
Create release / Create release from merged PR (pull_request) Has been skipped
efd90376d8
Continuation of LC-170. The enclave settings page (/enclave/{id}/settings) renders its own member list carrying the kick / role-toggle / transfer controls and is where managers actually work, but it did not subscribe to the enclave topic, so it stayed static until reload. LC-170 already broadcasts EnclaveMember{Added,Removed,RoleChanged} on the enclave:{id} topic; this wires the settings page as a second consumer.

- The settings member list is extracted into a shared partial (enclave/settings_members_items.html) so the page and the live OOB fragment (ws/enclave_settings_members_live.html, swapping #lc-enclave-settings-members) render identically. The unrelated settings sections (visibility, invite code, emojis, groups, branding, delete) stay in the page untouched.
- The settings page now carries data-lc-live-topic="enclave:{id}". topic_subscribe_allowed already authorizes enclave members and (LC-170 review) site admins; get_settings already 403s non-managers, so only managers reach the page.
- render_enclave_members now takes the recipient and emits BOTH member fragments in one frame: the read-only landing list (#lc-enclave-members, recipient-independent) and the settings list (#lc-enclave-settings-members, rendered per recipient because the kick/role/transfer controls gate on can_delete). A connection on the landing page matches only the first id, a connection on settings only the second, and htmx silently drops the unmatched OOB target. The enclave row is fetched once for the settings variant; if it is gone the landing fragment is the sole output.

Out of scope: the User groups section on the settings page has no broadcast events today (group CRUD fires nothing), so live group updates are deferred rather than wired here.

Regression test asserts the settings page subscribes to the topic, renders the swappable member region, and still shows the manager controls inside it.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
nrupard deleted branch feat/lc-172-live-settings-members 2026-05-26 18:00:24 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/lets-chat!217
No description provided.