mahmoodandClaude Sonnet 5.5
5f3b00497e
Experts (AdminUser) and customers (Customer) sign in to the same apps by mobile but live in different tables, so the database cannot make the number unique across them. A number could be given to an expert and to a customer, and the login then silently merged the two (the customer row was adopted as the expert's trading account), which left the expert on a customer session and the panel's name edits unreachable. The reference rejected a duplicate at entry (`unique:customers`, the agent being a customers row too); this does the same where a number is typed in: - customer create/update (wholesale, banker, walk-in): refused when an ACTIVE expert holds the number; - expert create/update: refused when a customer holds it (the expert's own trading account excepted); - the app's self sign-up: refused when an active expert holds it. Only a number being created or CHANGED is checked, so existing duplicates keep signing in and stay editable; the login's "expert wins" adoption is untouched. Plain equality on the two unique columns, normalised with faToEn, so both lookups are index hits. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
henza_admin
@ 1b67448143
henza_pwa
@ b171ffffb5
henza_server
@ 37c7d7a92f