Redesign user account page with separated password flow

[thomasbeaudry]

Summary

• Rename "Preferences" to "Account" in the sidebar user dropup menu
• Redesign the user page with a profile card showing the user icon, username, role, and a Change Password button
• Separate password change into its own dialog with strength validation and confirmation
• Reorder personal info fields: first name, last name, date of birth, sex, email, phone number
• Remove the "Login Credentials" section; single "Personal Information" group
• Add phone number validation requiring at least 7 digits
• Add data-form-type="other" and data-lpignore="true" to prevent browser autofill

Test plan

• Verify the sidebar dropup shows "Account" (en) / "Compte" (fr) instead of "Preferences"
• Verify the profile card displays the user icon, username, and role
• Verify the Change Password button opens a dialog with password + confirm fields and strength indicator
• Verify submitting the profile form saves all fields except password
• Verify phone numbers with fewer than 7 digits are rejected
• Verify autofill does not populate the form with browser-saved data
• Run pnpm lint and pnpm test — both pass (46 test files, 338 tests)

🤖 Generated with Claude Code

[gdevenyi]

Review — account page redesign

Separating the password change from the profile form is the right call, and it removes a genuinely awkward bit of the old code (the password && password === confirmPassword reconciliation inside onSubmit). The password schema is now unconditionally strict instead of if (ctx.value.password)-guarded, which is a real improvement. Field reordering and the "Preferences" → "Account" rename both make sense.

I checked the two things most likely to be silently broken and they're fine: libui's Form declares [key: \data-${string}`]: unknownand spreads...propsonto the

, so data-form-type/data-lpignoredo reach the DOM; and Tailwind 4.3's dynamic spacing scale makesh-18 w-18` valid.

Should fix

1. Unhandled rejection when a password change fails. void mutateAsync({...}).then(() => setIsPasswordDialogOpen(false)) has no .catch. mutateAsync rejects on error, so a rejected password (breached, too weak server-side) produces an unhandled promise rejection. The axios interceptor still shows a toast, so it's not silent — but the dialog stays open with no local indication and the error escapes the promise chain.

2. The digit minimum only applies on this page. MIN_PHONE_DIGITS is enforced in user.tsx but not in admin/users/create.tsx, which still validates with bare PHONE_REGEX. An admin can create a user with a 5-digit phone number that the user then cannot save from their own account page without changing it. Same rule, two places — it should live with the regex.

3. Hardcoded bg-sky-700 on the Change Password button alongside variant="primary". This instance supports admin-configured branding (customPrimaryColor, eight login themes), and this button opts out of all of it. (#1439 does the same on its Select.Triggers — worth fixing the pattern in both.)

4. No tests for anything this PR actually changes. AGENTS.md requires unit tests and e2e tests in testing/ for new changes. The two new test files cover countPhoneDigits and PHONE_REGEX; nothing covers the behaviour the PR is about — that the profile form no longer submits a password, that the dialog opens and closes on success, or that a sub-7-digit number is rejected through the schema. The test plan's six manual checkboxes are all unchecked.

Smaller

5. permissionLabels: { [key: string]: string } over a closed enum — see inline.
6. py-[0.633rem] is a magic value; w-60 is an arbitrary fixed width that will sit oddly with "Changer le mot de passe" vs "Change Password".
7. it('should be 7') asserts a constant equals its literal — it can only fail when someone deliberately changes the constant, at which point they'll just update the test.
8. The user's name no longer appears anywhere except as form inputs — the old header showed fullName, username and role. Deliberate? An "Account" page that never says who you are reads a little odd, especially for shared workstations.
9. <Card> containing only a <Card.Header>, and a <div className="flex items-center gap-4"> wrapping a single button — both are structure with nothing to do.
10. The profile onSubmit still filters out empty strings, so a user can't clear an email or phone number once set — pre-existing, but this PR is the natural place to fix it now that the password no longer needs the same filter.

Coordination

This is the only one of the five open PRs (#1439, #1441, #1442, #1443, #1444) that merges cleanly against all the others — no shared files. Nice.

[gdevenyi]

mutateAsync rejects on failure and there's no .catch, so a rejected password change (server-side strength check, breached-password rejection, 5xx) becomes an unhandled promise rejection. The dialog also stays open with no local error state — the only feedback is the global axios error toast behind it.

mutate with callbacks avoids both:

onSubmit={(data) => {
  updateSelfUserMutation.mutate(
    { data: { password: data.password }, id: currentUser!.id },
    { onSuccess: () => setIsPasswordDialogOpen(false) }
  );
}}

The profile form above has the same shape (void updateSelfUserMutation.mutateAsync(...) with no catch) — pre-existing, but worth fixing in the same pass since both are touched here.

[gdevenyi]

The new minimum is enforced only in user.tsx. apps/web/src/routes/_app/admin/users/create.tsx still validates with z.union([z.literal(''), z.string().regex(PHONE_REGEX)]) and no digit check, so an admin can create a user with a 5-digit phone number that the user then can't save from their own account page — the field is pre-populated with a value their own form rejects.

Since PHONE_REGEX and MIN_PHONE_DIGITS are two halves of one rule, exporting the composed schema from here would make it impossible to apply one without the other:

export const $PhoneNumber = z.union([
  z.literal(''),
  z.string().regex(PHONE_REGEX).refine((v) => countPhoneDigits(v) >= MIN_PHONE_DIGITS)
]);

(The message needs t(), so it'd take the translator as an argument — same shape the useMemo'd schema uses today.)

Worth noting the two rules overlap: PHONE_REGEX already carries a (?=.{5,}) lookahead. Two independent minimums that can disagree is exactly the "two artifacts that must agree" case AGENTS.md warns about — folding the digit count in and dropping the lookahead would leave one rule.

[gdevenyi]

The key set here is closed — it's $BasePermissionLevel ('ADMIN' | 'GROUP_MANAGER' | 'STANDARD'). AGENTS.md: "No loose records where a closed key set is known."

const permissionLabels: Record<BasePermissionLevel, string> = { ... };
const permissionLevel = userInfo.data.basePermissionLevel
  ? permissionLabels[userInfo.data.basePermissionLevel]
  : undefined;

That makes the typeof … === 'string' guard unnecessary (it isn't really checking anything — it can't distinguish a valid level from any other string) and turns a future fourth permission level into a compile error instead of a silently blank line in the profile card.

[gdevenyi]

variant="primary" already resolves the themed primary colour, and bg-sky-700 … hover:bg-sky-800 overrides it with a fixed one. Instances can configure customPrimaryColor and pick among eight login themes ($BrandingConfig in schemas/setup), so on a branded deployment this is the one button that doesn't match anything around it. Dropping the colour classes and keeping the variant is enough.

w-60 (15rem) is also arbitrary for a button whose label is "Change Password" in English and "Changer le mot de passe" in French — the two want quite different widths, and a fixed one serves neither. w-fit with padding would.

(#1439 hardcodes the same bg-sky-700 family on its Select.Triggers — if you're touching this, worth aligning both.)

[gdevenyi]

py-[0.633rem] reads as a value tuned until one screenshot lined up. Nothing else in the app uses it, and the next person to change the icon size or title line-height won't know what it was compensating for. A scale value (py-2.5 = 0.625rem, within 0.13px of this) would behave identically and stay meaningful.

Structurally: this <Card> has only a Card.Header and no Card.Content, and the <div className="flex items-center gap-4"> on line 132 wraps a single <Button>. Both can go.

[gdevenyi]

This asserts a constant equals its own literal, so it can only fail when someone deliberately edits the constant — and then they'll edit this line too. It doesn't pin behaviour; the countPhoneDigits cases above already do that.

What's actually missing is a test of the rule: that a phone number with 6 digits is rejected and one with 7 is accepted, through whatever schema enforces it. That's the behaviour a user experiences, and right now nothing covers it.

Same for the rest of the PR — there's no test that the profile form no longer submits a password, or that the dialog closes only on a successful change. AGENTS.md also asks for an e2e spec in testing/ for new changes; testing/src/pages/_app/ has the page-object pattern ready for a user.page.ts.

[joshunrau]

Thanks — separating the password change into its own dialog is the right call, and the page reads much better for it. A few things need fixing before this lands.

The main one: the new "must contain at least 7 digits" message never actually reaches the user. Because the phone field is a z.union([z.literal(''), ...]), Zod discards the inner issue and reports a single invalid_union error, so the field just says "Invalid input" — in English, even in French. I reproduced this against the repo's Zod with "514-555", "12345" and "abcdefgh"; all three yield { code: 'invalid_union', path: ['phoneNumber'], message: 'Invalid input' }. Rewriting it as a single z.string() with a .check() that allows the empty string will let both the format error and the digit-count error carry their own translated message. (apps/web/src/routes/_app/user.tsx:58-77)

Related: the 7-digit rule only applies here. admin/users/create.tsx:233 and admin/users/index.tsx:61 still use PHONE_REGEX on its own, so an admin can save a phone number that the user is then blocked from re-saving on their own account. Worth exporting one shared $PhoneNumber schema from utils/validation.ts and using it in all three places.

On tests — the repo asks for a unit test and an e2e test per change. /user has no e2e page object or spec at all today, so the rename and the new dialog aren't covered anywhere. Could you add one in testing/ covering the dropup label, opening the dialog, rejecting a weak password, and a successful change closing the dialog? And in validation.test.ts:45-48, the MIN_PHONE_DIGITS should be 7 case just restates the constant — testing the schema's behaviour there would have caught the union problem.

Smaller items:

• user.tsx:133 — the Change Password button sets bg-sky-700 text-white hover:bg-sky-800 on top of variant="primary", which overrides libui's theme colours via twMerge and makes it the only primary button in the app with its own palette. flex items-center justify-center is already in the button's base classes, and the fixed w-60 is tight for the French label.
• user.tsx:119 — py-[0.633rem] is an unexplained magic number.
• UserDropup.tsx:67 — data-testid="user-dropup-preferences" still says "preferences" after the rename. Nothing references it yet, so it's a free fix before the new e2e test depends on it. The gear icon on an "Account" entry is a bit off too.
• user.tsx:174,179 — common.email and common.phoneNumber already exist in translations/common.json; use the keys. "Change Password" (139, 215) and "Save" (200, 234) are each written inline twice, so they'd be better as keys as well.
• user.tsx:237-242 — the password dialog's mutateAsync(...).then(...) has no .catch(), so a failed request leaves an unhandled rejection. The axios interceptor does surface a notification, so the user isn't left in the dark, but it should be handled where the dialog state lives.
• user.tsx:40-49 — Record<BasePermissionLevel, string> instead of { [key: string]: string } would remove the need for the typeof === 'string' guard. Inherited rather than introduced, but you're already in the file.

[joshunrau]

Suggested model: Opus 5

Sizing the remaining work on this PR for whoever picks it up, human or agent. Redesigning the phone schema and deciding where the shared $PhoneNumber belongs — apps/web/src/utils/validation.ts or packages/schemas — is repo judgment, and the work reaches three route files plus a new e2e page object and spec in testing/.

[joshunrau]

This is a big improvement on the first round — the union fix in particular is done at the right level, by deleting the construct that caused the problem rather than patching the one field that showed it. I ran your new e2e specs against real servers and all thirteen pass, and lint and the unit tests are clean. Good catch on the admin sheet sending ''; that was blocking saves for any user without an email.

Five things to tidy up, none of them blocking:

• The password dialog's Dialog.Content has no Dialog.Description. Every other dialog in apps/web supplies one — FullscreenPreviewDialog.tsx uses an sr-only one where there's nothing meaningful to say. Without it Radix logs a warning and the dialog has no aria-describedby.
• "Account"/"Compte" is now written inline in both user.tsx and UserDropup.tsx. Since it's used twice it should be a key, and translations/user.json is already there.
• In apps/api/src/users/dto/update-user.dto.ts, the class still types email as string | undefined while its @ValidationSchema($UpdateUserData) now parses it to string | null | undefined. Prisma accepts null so nothing breaks today, but the type and the schema disagree, and the first data.email?.trim() written against that type would crash at runtime.
• admin/users/create.tsx got the shared phone schema but its email is still the raw z.email() from $CreateUserData, so typing an address and then clearing it fails with zod's untranslated English message and blocks submit — the same action works fine on the other two forms. It also sends phoneNumber: '' instead of going through clearedIfBlank.
• apps/api/src/users/dto/create-user.dto.ts still has its own phone regex with no minimum-digit rule, so the unified rule only holds in the browser; a direct API call can still create a user with a 3-digit number. That predates this PR, but it's the same rule you were consolidating, and packages/schemas looks like the right home for it.

If you hand this to Claude Code, Opus 5 is the right size — the items span apps/web, apps/api and packages/schemas, and two of them are design calls rather than mechanical edits.

Reviewed at commit 3bd731e.

[joshunrau]

This round lands it. The phone rule now has exactly one definition and both tiers read it, the create form no longer blocks on zod's untranslated message, and the dialog description is in place. I ran your two spec files against real api/gateway/web servers and all sixteen pass; lint and the unit tests are clean too.

Three small things left:

• common.save duplicates the core.save key that already exists with the identical English and French — including in admin/users/index.tsx, which this PR edits and which still uses core.save for the same button. Two keys for one string will drift the first time somebody adjusts the French; use core.save and drop the new one.
• In apps/api/src/users/dto/update-user.dto.ts, the two redeclared fields spell out null | string by hand. That is the same kind of hand-maintained agreement that caused the bug you just fixed — deriving them from the schema type (email?: UpdateUserData['email']) means the class cannot fall behind $UpdateUserData again.
• $User.phoneNumber deliberately still parses numbers stored before the 7-digit minimum, but $UpdateUserData validates with $PhoneNumber, and both the account form and the admin edit sheet resubmit the stored value on every save. So a user whose record holds a short number can't change their first name, and an admin can't edit that user at all, until the phone field is fixed. If that is what you want, fine — otherwise the write schema needs the same tolerance for a value that has not been touched.

If you hand this to Claude Code, Opus 5 is the right size — the items span apps/web, apps/api and packages/schemas, and the last one is a judgment call about existing data rather than a mechanical edit.

Reviewed at commit 5a7b88e.

[thomasbeaudry]

Thanks — all three are addressed in f14b6247, on top of a merge with current main.

common.save — dropped. It was a second key for a string core.save already had; both call sites in user.tsx now use core.save, matching admin/users/index.tsx.

update-user.dto.ts — the two fields are now UpdateUserData['email'] and UpdateUserData['phoneNumber'], so the class can't fall behind $UpdateUserData.

The stored short number — fixed rather than accepted. Being unable to change your own first name because of a number you never touched is a regression for existing data, and an admin being locked out of that user entirely is worse.

The fix treats the PATCH as carrying only what changed: omittedIfUnchanged keeps an untouched value out of the payload, and $PhoneNumber now takes the stored value so client-side validation lets it through too. Both halves are needed — otherwise the form refuses to submit, or the API rejects the value it just handed back.

Deliberately not a loosening of the write schema: an edited number is still held to the rule, and the API still rejects a short one. One gap worth naming — no e2e can cover this, because $CreateUserData now enforces the minimum, so a legacy record can't be seeded through the API. The unit tests in apps/web/src/utils/__tests__/validation.test.ts cover it instead.

pnpm lint and pnpm test are clean (54 files, 407 passed) and CI is green on all five checks. I did not re-run the Playwright specs after your run at 5a7b88e7 — the only change touching them since is the payload edit above.

Ready for another look when you have a moment.