- Ya
- 4 Septemba 2026, 16:54 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 84e231a
Forgot-password resolved the address typed on the form against two sources: the account e-mail, and the org mailbox flagged Primary on the member's settings. The second reads email_provider.mailboxes / member_mailboxes, rows that only exist once the org's mail provider has been configured and synced. An org that runs its mail somewhere we do not administer has no rows there at all. Harmony Home Loans moved from KamoMail to Google Workspace whose API is not set up yet, so both tables are empty for them, and their members' account e-mails are personal gmail/yahoo addresses. The address they actually type is their @harmonyhomeloans.net work address, which matched neither source, so every attempt logged RecoveryService.emailInitiate: no user found for email (not revealing) and returned "if this email is registered, a recovery link has been sent" having sent nothing. A password reset is a fundamental system flow; it must not depend on how an org configured its mailboxes. That address was on record the whole time, in members.email, which is written when the member is created and is independent of any provider. It is now the last identifier tried, on recovery and on login alike, after the account identifier and the Primary mailbox have both had their say — so nothing that already resolved changes meaning. Like a mailbox address it is org-scoped, so it names not just who is signing in but where: the unscoped login path takes the org ids with the account and restricts the sign-in to them, exactly as ad48f49 does for a mailbox. Without that, signing in by work address would have offered every workspace the account belongs to. An address naming two different accounts still authenticates neither.