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.