As an admin I want to create and edit full user profiles so that users start with their information pre-filled #37

New Issue

marcel · 2026-03-20T19:07:54+01:00

marcel commented

2026-03-20 19:07:54 +01:00

Background

The admin page currently manages users in a compact table row (login, password field, group selector, delete). With the profile fields added in #35 (first name, last name, birth date, email, contact), there is no room to add those inline. The admin should be able to pre-fill this data at account creation time so the user does not have to enter it themselves.

This requires a light overhaul of the admin user management section — moving from inline table editing to a proper per-user edit view.

Desired behaviour

User list (overview, replaces the current table):

Shows each user as a row: display name (or username if no name set), login, group badges, edit and delete buttons
"New user" button at the top opens the new user form

User create / edit form (new dedicated view or side panel):

All existing fields: login (username), initial password, group assignment
All profile fields from #35: first name, last name, birth date, email, contact notes
Password field on the edit form is optional — leave blank to keep the current password, fill in to override it (same behaviour as today)
Admin does not need to supply the current password when changing someone else's password (admin override)

UI options to consider

Two patterns are reasonable — pick one during implementation:

Dedicated route /admin/users/[id]/edit and /admin/users/new — full page, easy to link to, clean URL
Slide-out panel / modal — stays on the admin page, no navigation; works well for small forms

Given the number of fields (10+), a dedicated route is likely cleaner.

Implementation notes

Backend — the profile fields are already added by #35. Only the admin-override password change needs a separate code path:

PUT /api/users/{id} (already exists or extend it) should allow an admin (ADMIN_USER permission) to update profile fields and optionally set a new password without supplying a current password
The existing POST /api/users/me/password (from #35) still requires the current password — this is the self-service path

Frontend

Refactor src/routes/admin/+page.svelte — replace the inline user table with the new list + edit-view pattern
New routes src/routes/admin/users/new/ and src/routes/admin/users/[id]/ (or modal equivalent)
The tags and groups tabs on the admin page are unaffected

Testing

@WebMvcTest — admin can update another user's profile fields; admin can set a new password without current password; non-admin gets 403
E2E Playwright spec — create user with full profile, verify fields appear on the edit form; edit an existing user's name, verify it is reflected in the user list

Dependencies

#35 (profile page) — must be merged first so the DB columns and /api/users/me endpoints exist; this issue extends the admin path to the same data

## Background The admin page currently manages users in a compact table row (login, password field, group selector, delete). With the profile fields added in #35 (first name, last name, birth date, email, contact), there is no room to add those inline. The admin should be able to pre-fill this data at account creation time so the user does not have to enter it themselves. This requires a light overhaul of the admin user management section — moving from inline table editing to a proper per-user edit view. ## Desired behaviour **User list** (overview, replaces the current table): - Shows each user as a row: display name (or username if no name set), login, group badges, edit and delete buttons - "New user" button at the top opens the new user form **User create / edit form** (new dedicated view or side panel): - All existing fields: login (username), initial password, group assignment - All profile fields from #35: first name, last name, birth date, email, contact notes - Password field on the edit form is optional — leave blank to keep the current password, fill in to override it (same behaviour as today) - Admin does not need to supply the current password when changing someone else's password (admin override) ## UI options to consider Two patterns are reasonable — pick one during implementation: 1. **Dedicated route** `/admin/users/[id]/edit` and `/admin/users/new` — full page, easy to link to, clean URL 2. **Slide-out panel / modal** — stays on the admin page, no navigation; works well for small forms Given the number of fields (10+), a dedicated route is likely cleaner. ## Implementation notes **Backend** — the profile fields are already added by #35. Only the admin-override password change needs a separate code path: - `PUT /api/users/{id}` (already exists or extend it) should allow an admin (`ADMIN_USER` permission) to update profile fields and optionally set a new password without supplying a current password - The existing `POST /api/users/me/password` (from #35) still requires the current password — this is the self-service path **Frontend** - Refactor `src/routes/admin/+page.svelte` — replace the inline user table with the new list + edit-view pattern - New routes `src/routes/admin/users/new/` and `src/routes/admin/users/[id]/` (or modal equivalent) - The tags and groups tabs on the admin page are unaffected ## Testing - `@WebMvcTest` — admin can update another user's profile fields; admin can set a new password without current password; non-admin gets 403 - E2E Playwright spec — create user with full profile, verify fields appear on the edit form; edit an existing user's name, verify it is reflected in the user list ## Dependencies - **#35** (profile page) — must be merged first so the DB columns and `/api/users/me` endpoints exist; this issue extends the admin path to the same data

marcel added the feature label 2026-03-20 19:11:19 +01:00

marcel added the user label 2026-03-20 19:12:39 +01:00

marcel referenced this issue from a commit

2026-03-22 16:34:10 +01:00

feat(admin): add dedicated routes for admin user management (#37)

marcel referenced this issue

2026-03-22 16:35:00 +01:00

feat(admin): dedicated routes for user management (#37) #47

marcel closed this issue

2026-03-22 19:36:40 +01:00

Sign in to join this conversation.