Admin: change a customer's email address, for the locked-out case #337

New Issue

2026-09-09T16:04:31-05:00

bermudalamb commented

2026-09-09 16:04:31 -05:00

Found while settling #42. Recorded in docs/ops/account-recovery.md.

The gap

The email address is the root of trust for every self-service recovery route. A customer who loses access to it has no way back in, and that is the correct design — this shop holds no second proof of identity, and anything invented to fill that gap would be a weaker credential than the one it replaced.

So the route is manual, and it runs through the shop owner:

The customer makes contact by whatever means they have.
The owner verifies them against order history — items bought, dates, the shipping address on file. A stranger has none of that.
The owner changes the address on the account.

Step 3 does not exist. The admin customer screen can disable, enable and release reservations. It cannot change an email address. Until it can, the only answer to a locked-out customer is a hand-written database edit, which has no record of who did it or why.

Why it is its own issue rather than part of #42

It is an admin capability with its own questions, none of which the passkeys project has any business answering:

The old address must be told. The self-service change already sends emailChanged to the address being replaced, on the reasoning that it is the mail that catches an account takeover. An admin-initiated change is the one case where the person being notified may be exactly the intruder — which is the point of sending it, but the copy cannot be the same, because "if you did not make this change, contact us" is addressed to a customer who just did contact us.
The new address is unverified. The self-service path resets email_verified and sends a verification link. This one probably should too, and that needs deciding rather than assuming.
It needs an audit record. A hand edit leaves none. An admin action that can move an account to a new owner is the one that most needs to say who did it and when.
Sessions and credentials. An account being moved to a recovered address is in the same position as one being recovered by reset. #42 concluded that a reset takes every session and every passkey. The same reasoning likely applies here and should be stated rather than inherited by accident.

Scope

An email-change action on the admin customer detail screen, asking for a reason.
Notification to the old address, with its own copy.
Verification of the new address.
An audit record of the change.
A decision, written down, on what happens to sessions and passkeys.

Priority

Low until production is live and there are real customers with real order history to verify against. It becomes the highest-priority support gap the first time someone actually asks.

Related: #42 (account recovery policy), #33 (disabling customers), #332 (social sign-in, which adds accounts whose recovery route is not email at all).

Found while settling #42. Recorded in `docs/ops/account-recovery.md`. ## The gap The email address is the root of trust for every self-service recovery route. A customer who loses access to it has no way back in, and that is the correct design — this shop holds no second proof of identity, and anything invented to fill that gap would be a weaker credential than the one it replaced. So the route is manual, and it runs through the shop owner: 1. The customer makes contact by whatever means they have. 2. The owner verifies them against order history — items bought, dates, the shipping address on file. A stranger has none of that. 3. The owner changes the address on the account. **Step 3 does not exist.** The admin customer screen can disable, enable and release reservations. It cannot change an email address. Until it can, the only answer to a locked-out customer is a hand-written database edit, which has no record of who did it or why. ## Why it is its own issue rather than part of #42 It is an admin capability with its own questions, none of which the passkeys project has any business answering: - **The old address must be told.** The self-service change already sends `emailChanged` to the address being replaced, on the reasoning that it is the mail that catches an account takeover. An admin-initiated change is the one case where the person being notified may be exactly the intruder — which is the point of sending it, but the copy cannot be the same, because "if you did not make this change, contact us" is addressed to a customer who just did contact us. - **The new address is unverified.** The self-service path resets `email_verified` and sends a verification link. This one probably should too, and that needs deciding rather than assuming. - **It needs an audit record.** A hand edit leaves none. An admin action that can move an account to a new owner is the one that most needs to say who did it and when. - **Sessions and credentials.** An account being moved to a recovered address is in the same position as one being recovered by reset. #42 concluded that a reset takes every session and every passkey. The same reasoning likely applies here and should be stated rather than inherited by accident. ## Scope - An email-change action on the admin customer detail screen, asking for a reason. - Notification to the old address, with its own copy. - Verification of the new address. - An audit record of the change. - A decision, written down, on what happens to sessions and passkeys. ## Priority Low until production is live and there are real customers with real order history to verify against. It becomes the highest-priority support gap the first time someone actually asks. Related: #42 (account recovery policy), #33 (disabling customers), #332 (social sign-in, which adds accounts whose recovery route is not email at all).

bermudalamb referenced this issue from a commit

2026-09-09 16:36:38 -05:00

feat(admin): move a customer's account to an address they can reach (#337)

bermudalamb referenced a pull request that will close this issue

2026-09-09 16:36:54 -05:00

feat(admin): move a customer's account to an address they can reach (#337) #338

bermudalamb closed this issue

2026-09-09 16:38:35 -05:00

bermudalamb referenced this issue from a commit

2026-09-09 16:38:37 -05:00

Merge pull request 'feat(admin): move a customer's account to an address they can reach (#337)' (#338) from feature/337-admin-change-customer-email into main

bermudalamb referenced this issue from a commit