Stop collecting a name and work phone the server discards (MAPPS-431) #509

Merged

longjacksonle merged 1 commit from fix/MAPPS-431-profile-identity-fields into main

2026-08-10 19:26:55 +02:00

longjacksonle commented

2026-08-10 19:25:15 +02:00

Owner

MAPPS-431. SPA only, no server change.

Three fields, not one

The profile page sent first_name, last_name, phone, mobile, title, timezone and date_format_string. mokosh-server's UpdateUserRequest accepts email, mobile, title, role, status, timezone, date_format_string, the theme pair and login_location_alerts.

The first three are absent from the second, deliberately: PMS-512 removed them because bunyip owns identity and mokosh keeps a read-only cache, refreshed by upsert_user_from_oidc on every login. So the PUT succeeded, three keys reached no column, and the screen said "Saved". The typed values then sat there looking saved until the next reload put the old ones back.

The page already knew

IdentityStrip, at the top of the same screen, reads "Name, email, password, 2FA, sessions, and billing are owned by Bunyip. Change them there", with a link to Account Settings.

The card immediately below offered to edit the name anyway. The page contradicted itself inside one screen, and the half that was wrong was the half with the input boxes and the Save button. That is also why removing the inputs loses nothing: the name is already shown at the top and already linked to where it can be changed.

Bunyip owns phone (BUNYIP-139) and flows it as phone_number under the phone scope (BUNYIP-140). This SPA requests openid email offline_access profile, so that claim never arrives and users.phone is a cache of something nobody sends.

mobile is different: mokosh's own column, accepted, and it saves. A dead "Work phone" directly above a live "Mobile" was the most confusing possible arrangement of those two facts, so the survivor's help text now says which one this page owns.

Why not the other two options

Writing identity to bunyip is still blocked: the SPA's token is minted for mokosh's audience and bunyip's Resource Server refuses it (MAPPS-427, BUNYIP-252). It needs an audience change and a bunyip endpoint before it is even possible.

Re-opening a local write path reverses PMS-512 for no gain, because bunyip overwrites the names on the very next login. The value would survive until the user signs in again.

Testing

cargo fmt --all --check, cargo clippy --all-targets -- -D warnings, both guard scripts, cargo test --lib (292 passing, up from 291).

The new test is a recurrence guard scanning this module's own source: nothing may be added to the request body that UpdateUserRequest does not accept, and mobile must stay, since the distinction between the two is the entire point. It scans the file minus its own test module, because the assertion names the strings it forbids.

MAPPS-431. SPA only, no server change. ## Three fields, not one The profile page sent `first_name`, `last_name`, `phone`, `mobile`, `title`, `timezone` and `date_format_string`. mokosh-server's `UpdateUserRequest` accepts `email`, `mobile`, `title`, `role`, `status`, `timezone`, `date_format_string`, the theme pair and `login_location_alerts`. The first three are absent from the second, deliberately: PMS-512 removed them because bunyip owns identity and mokosh keeps a read-only cache, refreshed by `upsert_user_from_oidc` on every login. So the PUT succeeded, three keys reached no column, and the screen said "Saved". The typed values then sat there looking saved until the next reload put the old ones back. ## The page already knew `IdentityStrip`, at the top of the same screen, reads "Name, email, password, 2FA, sessions, and billing are owned by Bunyip. Change them there", with a link to Account Settings. The card immediately below offered to edit the name anyway. The page contradicted itself inside one screen, and the half that was wrong was the half with the input boxes and the Save button. That is also why removing the inputs loses nothing: the name is already shown at the top and already linked to where it can be changed. ## Work phone, for a related reason Bunyip owns `phone` (BUNYIP-139) and flows it as `phone_number` under the `phone` scope (BUNYIP-140). This SPA requests `openid email offline_access profile`, so that claim never arrives and `users.phone` is a cache of something nobody sends. `mobile` is different: mokosh's own column, accepted, and it saves. A dead "Work phone" directly above a live "Mobile" was the most confusing possible arrangement of those two facts, so the survivor's help text now says which one this page owns. ## Why not the other two options Writing identity to bunyip is still blocked: the SPA's token is minted for mokosh's audience and bunyip's Resource Server refuses it (MAPPS-427, BUNYIP-252). It needs an audience change and a bunyip endpoint before it is even possible. Re-opening a local write path reverses PMS-512 for no gain, because bunyip overwrites the names on the very next login. The value would survive until the user signs in again. ## Testing `cargo fmt --all --check`, `cargo clippy --all-targets -- -D warnings`, both guard scripts, `cargo test --lib` (292 passing, up from 291). The new test is a recurrence guard scanning this module's own source: nothing may be added to the request body that `UpdateUserRequest` does not accept, and `mobile` must stay, since the distinction between the two is the entire point. It scans the file minus its own test module, because the assertion names the strings it forbids.

longjacksonle added 1 commit

2026-08-10 19:25:15 +02:00

fix(profile): stop collecting a name and a work phone the server discards

Check / fmt + clippy + tests (pull_request) Successful in 1m37s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

a9e72dc2fa

MAPPS-431. The page offered First name, Last name and Work phone, and mokosh-server ignored all three: PMS-512 removed them from `UpdateUserRequest` because bunyip owns identity and mokosh keeps a read-only cache refreshed by `upsert_user_from_oidc` on every login. The PUT succeeded, the keys reached no column, and the screen said "Saved". The typed values then sat there looking saved until the next reload put the old ones back.

The page already knew. `IdentityStrip`, at the top of the same screen, says "Name, email, password, 2FA, sessions, and billing are owned by Bunyip. Change them there" and links to Account Settings. The card immediately below offered to edit the name anyway, so the page contradicted itself within one screen, and the half with the input boxes and the Save button was the wrong half.

Work phone goes for a related reason: bunyip owns `phone` (BUNYIP-139) and flows it under the `phone` scope (BUNYIP-140), which this SPA does not request, so `users.phone` is a cache of something nobody sends. Mobile is mokosh's own column, is accepted, and does save. Showing a dead "Work phone" directly above a live "Mobile" was the most confusing possible arrangement of those two facts, so the survivor now says which one this page owns.

Writing identity to bunyip instead stays blocked: the SPA's token is minted for mokosh's audience and bunyip's Resource Server refuses it (MAPPS-427, BUNYIP-252). Re-opening a local write path was the other option and reverses PMS-512 for no gain, since bunyip overwrites the names on the next login.

The recurrence guard scans this module's own source: nothing may be added to the request body that `UpdateUserRequest` does not accept.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E48b8YHWYwmaKjFBy5esXp

longjacksonle scheduled this pull request to auto merge when all checks succeed

2026-08-10 19:26:47 +02:00