fix: admin default theme not applied for new users; force LTR on login inputs#689
Open
xhzeem wants to merge 1 commit into
Open
fix: admin default theme not applied for new users; force LTR on login inputs#689xhzeem wants to merge 1 commit into
xhzeem wants to merge 1 commit into
Conversation
…inputs Two independent RTL/theming bugs: 1. Admin-configured default theme (themePolicy.defaultThemeId) never reached new user sessions. initializeTheme() (stores/theme-store.ts) reads the policy store synchronously on mount, but /api/admin/policy is only fetched after /api/config resolves (hooks/use-config.ts, explicitly "non-blocking") - a minimum of two chained network round trips. A brand-new user's synchronous theme init always finished first, so the default-theme branch always saw an empty policy and fell back to activeThemeId: null - which then got persisted, making the miss permanent instead of self-correcting on reload. Added a themeChoiceMade flag (persisted) to distinguish "user explicitly picked Default" from "never decided yet," and a one-shot subscription to the policy store that retroactively applies themePolicy.defaultThemeId once it loads, but only if the user hasn't made their own choice (initially or since boot). 2. Login inputs (JMAP endpoint, username, password, TOTP, admin password) inherited dir="rtl" from <html> in RTL locales, right- aligning credential fields that must always read LTR. Set dir="ltr" explicitly on each.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two separate bugs found while testing the RTL/Arabic work in #661 / #664.
1. Admin-configured default theme never reached new user sessions
initializeTheme()(stores/theme-store.ts) determines the effective theme synchronously on mount, including a fallback tousePolicyStore.getState().policy.themePolicy?.defaultThemeId. But/api/admin/policyis only fetched after/api/configresolves (hooks/use-config.ts, explicitly commented "non-blocking") — a minimum of two chained network round-trips. A brand-new user's theme init (pure sync/localStorage) always wins that race, so the policy-default branch always sees an empty policy and falls back toactiveThemeId: null— which then gets persisted, making the miss permanent instead of self-correcting on the next reload. New accounts were stuck on the built-in look regardless of what the admin configured as default.Fix: added a
themeChoiceMadeflag (persisted) to distinguish "user explicitly picked Default" from "never decided yet" — both currently look identical asactiveThemeId === null. Added a one-shot subscription to the policy store that retroactively appliesthemePolicy.defaultThemeIdonce policy actually loads, but only when the user hasn't made their own choice (neither before boot nor in the interim while waiting for policy).2. Login inputs right-aligned in RTL locales
The JMAP endpoint, username, password, and TOTP inputs on the login page (plus the admin password input) inherit
dir="rtl"from<html>when an RTL locale (ar/he/fa) is active, right-aligning fields that must always read left-to-right regardless of UI language — same category of bug as #664, just not covered there since it's plaindirinheritance rather than bidi character mirroring. Setdir="ltr"explicitly on each.Test plan
npx tsc --noEmit— cleannpx vitest run— same result as a cleanmain(one pre-existing, unrelated failure: the newly-mergedcalocale is missingemail_composer.toolbar.*keys added in a later commit than when Catalan was added — reproduces identically onmain, not touched by this PR)themePolicy.defaultThemeIdset boots into that theme; login fields stay LTR inar/he/fa