fix(admin-users): localized emails, set-password flow, verification & nav #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/admin-user-emails-and-nav"
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?
Why
Fixes a batch of issues found while testing admin user creation under
/users.Changes
Transactional emails
Mailer.sendVerification/sendPasswordResetnow take the recipientlanguage; bodies are localized instead of hardcoded English. Callers (account.ts,me.ts) passuser.language.Mailer.sendSetPassword. Creating a user without a password now sends a welcome email with a first-password link instead of a bare "password reset was requested" mail.mail.footer.de/mail.footer.enwith sensible defaults, appended to every outgoing email by recipient locale. Editable in Admin → Settings (DE/EN textareas). Surfaced viaGET/PATCH /admin/settings.DIY-Avataremail subjects/bodies →wiederdabei.User creation
skip_verification: a password user created with the box unchecked is now created unverified and receives a verification email (and is blocked at login withemail_not_verified) instead of being silently auto-verified + welcomed.Admin nav / auth (the 403 storm)
landingPathFor(scopes). Login and boot now route users to a page their roles allow. Non-admins are no longer forced onto the admin-only dashboard, whose/admin/*calls 403 for them ("forbidden" screen).loadingstate and the SPA router is gated on the initial/auth/mecheck, so protected routes no longer bounce to the login form on refresh.Verification
#/dashboardwith repeated403s) and confirmed each fix:/dashboard.sendSetPassword; pw+skip=false → unverified + verify mail + login403; pw+skip=true → verified + welcome + login200; footer GET/PATCH/clear roundtrip.tsc --noEmitclean;svelte-check0 errors / 0 warnings; backend tests 358/360 (the 2 failingme.test.tscases are pre-existing onmaster, unrelated).Not addressed (not a code bug here)
The reported "reset/verify link wants me to authenticate first" did not reproduce: the reset/verify SPA routes and
POST /auth/reset/:token+/auth/verify/:tokenare public and work logged-out. Most likely deployment-side — checkADMIN_PUBLIC_BASE/ CORS-derived base and any reverse-proxy (Basic/SSO) auth on the admin origin.