mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-19 08:33:56 -06:00
1e99582193
On a fresh install with no users, typing an email address made the password field disappear. Identifier-first login asks the server which identity provider an address uses before offering a credential, so someone whose organization requires its own IdP is never shown a password box that will be refused. First-run setup opted out of that by setting `identified = true` up front - there is nobody to identify, the operator is creating the first account - and then the "editing the address returns to the identifier step" listener fired on the very first keystroke, set it back to false, and re-rendered. Password gone, mid-typing. The same re-render also replaced "Create admin account" on the button with "Sign in" and then "Next". Initialising a flag to the right value is not the same as the flow being inert: any later event could undo it, and one did. The decision now lives in frontend/js/lib/login-form-state.js as a pure function that ignores `identified` and `ssoOnlyDomain` entirely when there are no users, so no event can take a field away. The input listener also returns early during setup, which additionally stops it spending an org-lookup rate-limit budget that has nothing to answer. Two assertions in login-identifier-first.test.js pinned those expressions to their old address inside login.js. Their intent - "the two drivers must be combined in one place so they cannot disagree" - is better served by the extracted module, so they now follow the logic there rather than being loosened. Verified: the extracted pre-fix logic returns showPassword=false and buttonKey=auth.next for setup-plus-one-keystroke, which is the reported symptom exactly; the new truth table covers it. i18n/login/auth/session/sso suites go from 108 to 116 passing, none failing. Not addressed here, and worth its own change: loadAuthConfig() has no error handling and caches its first result, so a /api/auth/config that fails leaves needsSetup undefined and the form falls back to the restrictive layout - the same visible symptom from a different cause. Claude-Session: https://claude.ai/code/session_014kfhrUPit5MCqxeTQyqr56 Co-authored-by: Dan Walters <dan.walters@bytetinker.net> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| device-frame.js | ||
| login-form-state.js | ||
| schedule-grid.js | ||