feat(admin): expand user management with detail page + new actions #59
No reviewers
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
psa-systems/bunyip!59
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/admin-user-management"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The /admin/users page only exposed Make/Demote Admin and Delete. Backend
already supports more (suspend via /status, password-reset email, lifetime
grant, single-user fetch). Wire them up:
granted), Suspend. Each routed via a corresponding bunyip-web POST
handler that calls the matching bunyip-api endpoint.
every admin action in one place. Linked from the list View button so
admins can read full context before acting.
any rotated session cookies survive the form-submit hop. Was
redirect(...) which dropped Set-Cookies on the floor; same fix applied
to the new handlers up-front.
admin_reset_password, grant_lifetime. Mirror the existing thin
wrap-call-parse pattern.
Notes:
active=true (Cannot reactivate deleted users through this endpoint).
Tracked as follow-up; reactivation needs a new endpoint.
endpoint exists but the SSR flow for swapping the admin's bearer for
an impersonated user's needs its own design pass.
_ = with a redirect to the same surface, matching the pattern used by
the entitlement actions.
The /admin/users page only exposed Make/Demote Admin and Delete. Backend already supports more (suspend via /status, password-reset email, lifetime grant, single-user fetch). Wire them up: - New row actions: View, Reset Password, Lifetime (hidden if already granted), Suspend. Each routed via a corresponding bunyip-web POST handler that calls the matching bunyip-api endpoint. - New /admin/users/{id} detail page (GET) showing the user's profile + every admin action in one place. Linked from the list View button so admins can read full context before acting. - Existing user_role / user_delete handlers gained redirect_cookies so any rotated session cookies survive the form-submit hop. Was redirect(...) which dropped Set-Cookies on the floor; same fix applied to the new handlers up-front. - New api/admin.rs client methods: get_user, suspend_user, admin_reset_password, grant_lifetime. Mirror the existing thin wrap-call-parse pattern. Notes: - Suspend is one-way today: the backend rejects PUT /status with active=true (Cannot reactivate deleted users through this endpoint). Tracked as follow-up; reactivation needs a new endpoint. - Impersonate is intentionally NOT exposed in this UI - the backend endpoint exists but the SSR flow for swapping the admin's bearer for an impersonated user's needs its own design pass. - All write actions go through admin_guard; failures bubble through let _ = with a redirect to the same surface, matching the pattern used by the entitlement actions.