Offer a support email alongside the organisation contact (PMS-755) #510
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/PMS-755-org-support-email"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
PMS-755. The SPA half is mokosh-apps #506.
Context first, because most of the ticket was already done
The ticket was raised looking at
/settings/organizationon staging, which shows one field. MAPPS-429 merged earlier today and added the contact name, phone and logo to exactly that page; staging is serving the SPA build immediately BEFORE that merge, and an API image from before its server merge. So the screenshot is the last build without them, and a redeploy answers most of the question.What is genuinely missing afterwards is an email address, which is this PR.
What changed
The organisation contact was a name and a phone number, so a client reading "Contact the service desk at Acme IT on 555-0100" had exactly one channel, and it was the one requiring them to be at a phone during business hours.
TenantBrandinghas declaredsupport_emailsince migration 002 with nothing ever reading or writing it, so there is no migration and no new field: only a consumer.The preposition now belongs to the channel rather than to the sentence. "on" reads right before a number and wrong before an address, so a phone renders "on 555-0100", an email renders "by email at help@acme.example", and both render as the two joined. Composed in one place so the email and the client's form page cannot word the same two facts differently.
The form page needed its own shape: it writes "Contact {phrase}.", and a phrase that opens on a preposition reads as a broken sentence. With no contact person set it falls back to the organisation's name, so that line never opens on a phone number.
A form that defines its own
contact_infostill wins over all of it, unchanged from PMS-748.What this deliberately does not add
Recorded in the ticket so nobody adds them by reflex: postal address, opening hours and website (nothing renders them); colours, favicon and portal domain (declared on
TenantBranding, also unread, and they belong to a portal-theming ticket that renders them); andbilling_email/billing_contact_name, which are who an invoice goes to rather than who a client should ask.Testing
cargo fmt --all --check,cargo clippy --all-targets(clean),cargo test --lib(11 tests in this module). Two new ones: every combination of name, phone and email produces a sentence that reads correctly rather than one with a dangling preposition, and the form-page phrase never opens on one.PMS-755. The organisation contact was a name and a phone number, so a client reading "Contact the service desk at Acme IT on 555-0100" had exactly one channel, and it was the one that requires them to be at a phone during business hours. `TenantBranding` has declared `support_email` since migration 002 with nothing ever reading or writing it. The preposition now belongs to the channel rather than to the sentence: "on" reads right before a number and wrong before an address, so a phone is "on 555-0100", an email is "by email at help@acme.example", and both is the two joined. Composed in one place so the email and the client's form page cannot word the same two facts differently. The form page needed its own shape, because it writes "Contact {phrase}." and a phrase opening on a preposition reads as a broken sentence. With no contact person set it falls back to the organisation's name, so the line never opens on a phone number. A form that defines its own contact still wins over all of it, unchanged from PMS-748. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E48b8YHWYwmaKjFBy5esXp