feat(enclave): user-groups CRUD UI #144

Merged

nrupard merged 1 commit from feat/lc-83-user-groups-ui into main

2026-05-18 20:40:14 +02:00

nrupard commented

2026-05-18 20:39:28 +02:00

Owner

Stacks on #143 (feat/lc-83-user-groups). PR #143 shipped the per-enclave user-groups API and the @group-name mention expansion but deliberately skipped the UI, so admins could only manage groups via curl. This adds the UI to the existing enclave-settings page.

What you get:

A new User groups section below Custom emojis on /enclave/{id}/settings listing every group, member count, and a label chip per member (display_name or @username, resolved server-side).
Create-group form (name only) at the bottom of the section.
A collapsible Add member form per group, taking a user id.
Delete button per group using hx-delete (HTML forms cannot issue DELETE) with hx-confirm and a post-request soft reload.

Handler changes:

routes/user_groups.rs now returns Redirect::to("/enclave/{id}/settings") from every mutation instead of bare 200, so plain HTML forms (create, add-member) land back on the settings page. Existing tests updated from OK to SEE_OTHER.
routes/enclave.rs::get_settings resolves group member labels (looks up display_name / username) once and passes them to the template.
views/enclave.rs gains an EnclaveGroupView and a groups field on EnclaveSettingsPage.

Validated with just check (server, desktop, clippy both feature sets, fmt) and the routes_user_groups integration suite (3/3 passing). Not landing the member-remove button this PR; the per-member chip render is read-only for now and follows in a small follow-up if anyone asks.

Stacks on #143 (`feat/lc-83-user-groups`). PR #143 shipped the per-enclave user-groups API and the `@group-name` mention expansion but deliberately skipped the UI, so admins could only manage groups via curl. This adds the UI to the existing enclave-settings page. What you get: - A new `User groups` section below `Custom emojis` on `/enclave/{id}/settings` listing every group, member count, and a label chip per member (display_name or `@username`, resolved server-side). - Create-group form (name only) at the bottom of the section. - A collapsible `Add member` form per group, taking a user id. - Delete button per group using `hx-delete` (HTML forms cannot issue DELETE) with `hx-confirm` and a post-request soft reload. Handler changes: - `routes/user_groups.rs` now returns `Redirect::to("/enclave/{id}/settings")` from every mutation instead of bare `200`, so plain HTML forms (create, add-member) land back on the settings page. Existing tests updated from `OK` to `SEE_OTHER`. - `routes/enclave.rs::get_settings` resolves group member labels (looks up display_name / username) once and passes them to the template. - `views/enclave.rs` gains an `EnclaveGroupView` and a `groups` field on `EnclaveSettingsPage`. Validated with `just check` (server, desktop, clippy both feature sets, fmt) and the `routes_user_groups` integration suite (3/3 passing). Not landing the member-remove button this PR; the per-member chip render is read-only for now and follows in a small follow-up if anyone asks.

nrupard added 1 commit

2026-05-18 20:39:28 +02:00

feat(enclave): user-groups CRUD UI in enclave settings 6497b02b1f

LC-83 follow-up. PR #143 shipped the API but no UI, so admins could only manage groups via curl. Adds a Groups section to the enclave settings page that lists existing groups with member labels, a create-group form, an add-member form per group, and a delete button using `hx-delete` (HTML forms cannot issue DELETE). Admin handlers now redirect back to the settings page instead of returning bare 200s, and tests assert 303 SEE_OTHER.

Resolved member labels (display_name or @username) are computed in the route so the template stays presentation-only.