Collect an organisation contact and logo (MAPPS-429) #505

Merged

longjacksonle merged 1 commit from feat/MAPPS-429-org-contact-and-logo into main

2026-08-10 18:51:53 +02:00

longjacksonle commented

2026-08-10 18:49:25 +02:00

Owner

MAPPS-429, SPA half. Needs mokosh-server #509 (the branding fields, the logo endpoints, and the contact fallback) and, for the emailed logo to appear on a deployment, NiceGuyIT/docker #331.

David asked for organisation-level metadata rather than user identity, which is what unblocked this ticket: PMS-512 gave user names to bunyip and left mokosh unable to write them, and none of that applies to tenant fields.

Settings, Organization

Gains a contact name, a contact phone and a logo.

The two text fields ride the existing tenant PUT. The logo does not: it is a file, it goes up as multipart, and it uploads on selection rather than on Save. A file input whose effect waits for a Save button is one people forget to press, and the two requests are unrelated anyway.

Onboarding

Collects the same three. Contact name and phone are required, since a client receiving a request form should always have someone to ask.

The logo is optional and is held in memory until the rest of the screen saves, because a logo attached to a tenant whose details were never submitted is litter. If that upload then fails, onboarding still completes and says so in a toast: refusing to finish over the one optional field on the screen would trap the user, which is the failure mode PMS-752 just removed from this page.

What clients see

The client's form page renders the logo above the MSP's name. Someone opening a link from an email recognises a logo before they read a word, and that page asks them for personal details.

Both builder previews render it as well, from the same fetch that already supplies the organisation name, so an operator signing off on a form sees what their client will see.

The multipart helper

New in hooks/fetch. The body is assembled by the browser from a FormData carrying a Blob, so the boundary is the browser's problem; writing the envelope by hand would mean generating a boundary and hoping it never occurs inside the image bytes.

It deliberately does not set Content-Type. Setting it manually omits the boundary parameter, and the server then cannot split a body it was just handed. That is the one thing worth knowing if this helper is reused.

Adds two web-sys features (FormData, BlobPropertyBag); Blob was already enabled for the MAPPS-364 export download.

Testing

cargo fmt --all --check, cargo clippy --all-targets -- -D warnings, both guard scripts, cargo test --lib (288 passing). The preview test now also asserts the logo rides along, since the preview being wrong about the sender is exactly the class of bug PMS-752 fixed.

Everything else here is a fetch, a file input and an <img>, which nothing can exercise while the browser-driven e2e specs are quarantined. Worth eyeballing on staging after both merge: upload a logo in Settings, preview a form, then send yourself one and check the email.

MAPPS-429, SPA half. Needs mokosh-server #509 (the branding fields, the logo endpoints, and the contact fallback) and, for the emailed logo to appear on a deployment, NiceGuyIT/docker #331. David asked for organisation-level metadata rather than user identity, which is what unblocked this ticket: PMS-512 gave user names to bunyip and left mokosh unable to write them, and none of that applies to tenant fields. ## Settings, Organization Gains a contact name, a contact phone and a logo. The two text fields ride the existing tenant PUT. The logo does not: it is a file, it goes up as multipart, and it uploads **on selection** rather than on Save. A file input whose effect waits for a Save button is one people forget to press, and the two requests are unrelated anyway. ## Onboarding Collects the same three. Contact name and phone are required, since a client receiving a request form should always have someone to ask. The logo is optional and is held in memory until the rest of the screen saves, because a logo attached to a tenant whose details were never submitted is litter. If that upload then fails, onboarding still completes and says so in a toast: refusing to finish over the one optional field on the screen would trap the user, which is the failure mode PMS-752 just removed from this page. ## What clients see The client's form page renders the logo above the MSP's name. Someone opening a link from an email recognises a logo before they read a word, and that page asks them for personal details. Both builder previews render it as well, from the same fetch that already supplies the organisation name, so an operator signing off on a form sees what their client will see. ## The multipart helper New in `hooks/fetch`. The body is assembled by the browser from a `FormData` carrying a `Blob`, so the boundary is the browser's problem; writing the envelope by hand would mean generating a boundary and hoping it never occurs inside the image bytes. It deliberately does not set `Content-Type`. Setting it manually omits the boundary parameter, and the server then cannot split a body it was just handed. That is the one thing worth knowing if this helper is reused. Adds two `web-sys` features (`FormData`, `BlobPropertyBag`); `Blob` was already enabled for the MAPPS-364 export download. ## Testing `cargo fmt --all --check`, `cargo clippy --all-targets -- -D warnings`, both guard scripts, `cargo test --lib` (288 passing). The preview test now also asserts the logo rides along, since the preview being wrong about the sender is exactly the class of bug PMS-752 fixed. Everything else here is a fetch, a file input and an `<img>`, which nothing can exercise while the browser-driven e2e specs are quarantined. Worth eyeballing on staging after both merge: upload a logo in Settings, preview a form, then send yourself one and check the email.

longjacksonle added 1 commit

2026-08-10 18:49:26 +02:00

feat(settings): collect an organisation contact and logo

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

Details

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

Details

58d7de4cea

MAPPS-429, SPA half of the organisation metadata David asked for. Needs mokosh-server #509.

Settings > Organization gains a contact name, a contact phone and a logo. The two text fields ride the existing tenant PUT; the logo does not, because it is a file and goes up as multipart, and it uploads on selection rather than on Save. A file input whose effect waits for a Save button is one people forget to press.

Onboarding collects the same three, with the contact name and phone required, since a client who receives a request form should always have someone to ask. The logo is optional and is held in memory until the rest of the screen saves: a logo attached to a tenant whose details were never submitted is litter. Its upload failing does NOT block completion, because refusing to finish onboarding over the one optional field would trap the user.

The client's form page renders the logo above the MSP's name. Someone opening a link from an email recognises a logo before they read anything, and that page asks them for personal details. Both builder previews render it too, from the same fetch that supplies the name, so an operator signing off on a form sees what the client will.

The multipart helper is new: the body is assembled by the browser from a FormData carrying a Blob, so the boundary is the browser's problem. It deliberately does not set Content-Type, because setting it by hand omits the boundary parameter and the server then cannot split a body it was handed.

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