Feature/106 customer first last name #109

2026-08-21T18:39:43-05:00

bermudalamb commented

2026-08-21 18:39:43 -05:00

No description provided.

bermudalamb self-assigned this 2026-08-21 18:39:43 -05:00

bermudalamb added this to the Make the password-reset email editable from Admin project 2026-08-21 18:39:43 -05:00

bermudalamb added 2 commits 2026-08-21 18:39:44 -05:00

fix(test): make the compose guard survive a CRLF checkout (#107 ) f76db6c8fe

The guard added for #107 finds nothing on a checkout with CRLF line endings, which is every fresh clone on Windows. Splitting on a bare newline leaves a trailing carriage return, the end-of-line anchor in the entry pattern then cannot match, and all ten assertions in the file fail together.

Worth being precise about why this shipped, because the process that was supposed to prevent it ran and did not. That guard was fired deliberately before committing: the UPLOADS_DIR line was removed, two tests failed, the line was restored, ten passed. What the exercise never varied was the file's line endings — and by then the working copy happened to be LF, because the backup-and-restore used to fire the guard had rewritten it that way. So the deliberate firing proved the guard catches a missing variable, on a file shaped exactly as the test run had shaped it, and proved nothing about the shape it meets in a clean clone.

The failure mode is the one the file already worried about: parsing that matches nothing makes every other assertion vacuously true. Here it failed loudly instead only because the "parsed some entries at all" case exists — which is the case that turned a silent pass into a visible failure, and is the reason this was noticed at all rather than sitting green and checking nothing.

Splitting on an optional carriage return fixes it. 172 unit tests pass on the CRLF checkout that was failing.

Found while verifying #106, whose branch could not go green until this was fixed, which is why the fix lands there rather than on its own.

Refs #107
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

feat: capture first and last name so emails can greet informally (#106 )

Tests / lint (pull_request) Successful in 1m38s

Details

Tests / backend-unit (pull_request) Successful in 1m44s

Details

Tests / frontend-e2e (pull_request) Failing after 9m50s

Details

SonarQube Analysis / sonarqube (pull_request) Failing after 11m46s

Details

b287c07747

Registration collected one optional Name, so every greeting had only a whole name to use: "Hi Thom Lamb," rather than "Hi Thom,". Both parts are now captured, and the cart reminder greets by first name.

Both are required of anyone new, refused individually rather than as a single "name is required" so a form that filled one and not the other is told which.

The columns are nullable even so, and that is deliberate. Marking them NOT NULL would mean backfilling legacy rows with empty strings, which asserts that every customer has a name — untrue of anyone who registered while the field was optional. The table records what is actually the case; the rule that new registrations must supply both lives in the route, where a missing field can produce a message naming it.

The backfill splits on the first space, and it is lossy in a way no version of this avoids. "Thom Lamb" becomes Thom and Lamb; "Mary Jane Smith" gets a last name of "Jane Smith"; names that are not two parts fare worse. It was chosen over leaving the columns empty because nothing currently lets a customer correct their own name — PUT /api/customers/me exists but no frontend calls it — so empty would have meant permanently unpersonalised for every existing customer. The migration says so, so nobody later reads backfilled values as data the customer supplied in that shape.

Verified against a seeded database rather than reasoned about, because this is the part that cannot be covered by the suite: migrations run in globalSetup before any test, and the old column is gone afterwards. Six representative rows through the real migration gave Thom/Lamb, Mary/"Jane Smith", Cher/null, "  Padded  Name  " trimmed to Padded/Name, and null and whitespace-only names left as null on both. The down migration rejoins the parts and returns all six to their original strings.

The old column is dropped rather than kept alongside, so there is one source of truth instead of two that drift.

The admin keeps receiving a single composed display name. It only ever shows one — the list cell and the drawer title — and never edits one, so giving it both parts plus the joining logic would be work for no reader.

Churn was the bulk of this: 14 backend registrations and 10 end-to-end registration forms. A first attempt at the backend fixtures also added names to login and password-reset payloads, which would still have passed since the server ignores unknown fields, but a login test implying login takes a name is a small lie; that was reverted and redone against register calls only.

Verified: 172 unit, 183 integration and 95 end-to-end passing, lint unchanged at 4 backend and 27 frontend warnings.

Not covered: the cart reminder itself, which runs from a cron and had no test before this either. The greeting change is a one-line substitution in that query.

Refs #106
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

bermudalamb merged commit 3b3888fd3c into main

2026-08-21 18:42:00 -05:00

bermudalamb deleted branch feature/106-customer-first-last-name

2026-08-21 18:42:02 -05:00

bermudalamb moved this to Review in Make the password-reset email editable from Admin on 2026-08-21 18:47:47 -05:00

bermudalamb moved this to Ready for Release in Make the password-reset email editable from Admin on 2026-08-21 18:59:57 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#109