A customer cannot change their own details — PUT /api/customers/me has no caller #111

New Issue

2026-08-21T18:59:31-05:00

bermudalamb commented

2026-08-21 18:59:31 -05:00

Whatever a customer types at registration is permanent. There is no way to correct a misspelled name, and nothing on the account page edits anything.

The endpoint already exists. PUT /api/customers/me updates the name and returns the public customer shape — and no frontend code calls it, confirmed by grep while working on #106. It is API surface with no caller, which is why the gap is easy to miss: the backend looks finished.

Why it matters more after #106

#106 split the single optional name into a required first and last name, and backfilled existing rows by splitting on the first space. That backfill is deliberately lossy and says so: "Mary Jane Smith" ends up with a last name of "Jane Smith", and names that are not two parts fare worse.

The migration accepted that specifically because there was no way for a customer to correct their own record — the alternative, leaving the fields empty, would have left those customers permanently unpersonalised with no recourse. This issue is the recourse. Until it exists, a mangled backfill is a mangled name forever.

What it needs

A form on the account page for first and last name, wired to the endpoint that is already there. The endpoint itself needs its validation brought in line with registration, which requires both names and refuses each by name — right now it accepts empty values and writes nulls, which would let a customer clear the fields registration insists on.

Worth deciding, and these are the reasons this is not trivial

Email address. Changing it is a different kind of change: the new address is unverified by definition, so it needs the verification flow to run again, and the old address should probably be told. It also interacts with #110. The simplest honest answer is to leave email out of this issue and say so, rather than half-implement it.

Password. There is a working reset flow that goes through email. A change-password form on the account page needs the current password to be re-entered, or an account left open on a shared machine becomes an account takeover. Also arguably its own issue.

Marketing and favorite-alert consents. Both are already editable elsewhere on the account page and both store the exact wording shown at the time. They should not be folded into a general profile save that does not carry that wording, or the consent record stops describing what was agreed to.

The narrow version — first and last name only — is the one that unblocks the #106 backfill, and the other three are each a decision rather than an oversight.

Verification

Integration tests: an update stores both names, an empty name is refused the way registration refuses it, an unauthenticated call is refused, and one customer cannot update another. End to end: editing a name on the account page persists it across a reload, and the greeting in a subsequent email uses the corrected first name.

Severity

Low-medium. Nothing is broken, but a customer whose name was mangled by #106's backfill currently has no way to fix it, and that was an explicit assumption of accepting that backfill.

Whatever a customer types at registration is permanent. There is no way to correct a misspelled name, and nothing on the account page edits anything. The endpoint already exists. `PUT /api/customers/me` updates the name and returns the public customer shape — and **no frontend code calls it**, confirmed by grep while working on #106. It is API surface with no caller, which is why the gap is easy to miss: the backend looks finished. ## Why it matters more after #106 #106 split the single optional name into a required first and last name, and backfilled existing rows by splitting on the first space. That backfill is deliberately lossy and says so: "Mary Jane Smith" ends up with a last name of "Jane Smith", and names that are not two parts fare worse. The migration accepted that specifically **because there was no way for a customer to correct their own record** — the alternative, leaving the fields empty, would have left those customers permanently unpersonalised with no recourse. This issue is the recourse. Until it exists, a mangled backfill is a mangled name forever. ## What it needs A form on the account page for first and last name, wired to the endpoint that is already there. The endpoint itself needs its validation brought in line with registration, which requires both names and refuses each by name — right now it accepts empty values and writes nulls, which would let a customer clear the fields registration insists on. ## Worth deciding, and these are the reasons this is not trivial **Email address.** Changing it is a different kind of change: the new address is unverified by definition, so it needs the verification flow to run again, and the old address should probably be told. It also interacts with #110. The simplest honest answer is to leave email out of this issue and say so, rather than half-implement it. **Password.** There is a working reset flow that goes through email. A change-password form on the account page needs the current password to be re-entered, or an account left open on a shared machine becomes an account takeover. Also arguably its own issue. **Marketing and favorite-alert consents.** Both are already editable elsewhere on the account page and both store the exact wording shown at the time. They should not be folded into a general profile save that does not carry that wording, or the consent record stops describing what was agreed to. The narrow version — first and last name only — is the one that unblocks the #106 backfill, and the other three are each a decision rather than an oversight. ## Verification Integration tests: an update stores both names, an empty name is refused the way registration refuses it, an unauthenticated call is refused, and one customer cannot update another. End to end: editing a name on the account page persists it across a reload, and the greeting in a subsequent email uses the corrected first name. ## Severity Low-medium. Nothing is broken, but a customer whose name was mangled by #106's backfill currently has no way to fix it, and that was an explicit assumption of accepting that backfill.

bermudalamb self-assigned this 2026-08-21 19:01:40 -05:00

bermudalamb added this to the Make the password-reset email editable from Admin project 2026-08-21 19:01:53 -05:00

bermudalamb referenced this issue from a commit

2026-08-22 09:19:28 -05:00

feat(backend): let a customer change their own name, password and email (#111)

bermudalamb referenced this issue

2026-08-22 09:21:55 -05:00

feat(backend): let a customer change their own name, password and email (#111) #113

bermudalamb added reference feature/111-manage-account-details

2026-08-22 09:22:07 -05:00

bermudalamb moved this to Review in Make the password-reset email editable from Admin on 2026-08-22 09:22:13 -05:00

bermudalamb referenced this issue from a commit