Name the MSP on the client's request form (PMS-748) #499

Merged

longjacksonle merged 2 commits from feat/PMS-748-request-form-attribution into main

2026-08-09 19:34:43 +02:00

longjacksonle commented

2026-08-09 19:28:38 +02:00

Owner

PMS-748, SPA half. The server half (the email copy, the contact_info column, migration 102 and ABUSE_CONTACT_EMAIL) is mokosh-server #505 and this PR needs it: the attribution rendered here is served by that payload.

The client's form page names the MSP

A client opening a request-form link saw a title, a set of questions about a named employee, and nothing else. No indication of which MSP was asking, and no way to check before typing a phone number into it. The page now closes with who sent the form and, when the definition carries them, how to reach them.

Rendered inside the shared body component rather than around it, so the builder's preview shows an operator exactly what their client will read. That component has been the single source for both surfaces since PMS-744, and putting the block outside it would have reintroduced the drift that pattern exists to prevent.

The MSP name suppresses the whole block when empty, which is what a build talking to a server predating #505 receives. An empty attribution would otherwise render as a horizontal rule above nothing.

A form can carry contact details

New optional field in the builder, next to the procedure picker: free text ("the service desk on 555-0100"), shown to the client on the form and in the email that links to it. Optional because the MSP's name is shown either way; this is the channel, not the attribution.

Both previews carry it, the saved-definition one and the live editor one, so an operator adding a contact line sees where it lands before saving.

Testing

cargo fmt --all --check, cargo clippy --all-targets -- -D warnings, both guard scripts, cargo test --lib (274 passing, up from 273). The new test asserts the preview carries the attribution the client will see and that a contact field holding only spaces does not preview as a contact line.

Not covered by tests: the rendered block itself, which is markup. The browser-driven e2e specs are still quarantined, so this needs eyeballing on staging once both PRs are deployed.

PMS-748, SPA half. The server half (the email copy, the `contact_info` column, migration 102 and `ABUSE_CONTACT_EMAIL`) is mokosh-server #505 and this PR needs it: the attribution rendered here is served by that payload. ## The client's form page names the MSP A client opening a request-form link saw a title, a set of questions about a named employee, and nothing else. No indication of which MSP was asking, and no way to check before typing a phone number into it. The page now closes with who sent the form and, when the definition carries them, how to reach them. Rendered inside the shared body component rather than around it, so the builder's preview shows an operator exactly what their client will read. That component has been the single source for both surfaces since PMS-744, and putting the block outside it would have reintroduced the drift that pattern exists to prevent. The MSP name suppresses the whole block when empty, which is what a build talking to a server predating #505 receives. An empty attribution would otherwise render as a horizontal rule above nothing. ## A form can carry contact details New optional field in the builder, next to the procedure picker: free text ("the service desk on 555-0100"), shown to the client on the form and in the email that links to it. Optional because the MSP's name is shown either way; this is the channel, not the attribution. Both previews carry it, the saved-definition one and the live editor one, so an operator adding a contact line sees where it lands before saving. ## Testing `cargo fmt --all --check`, `cargo clippy --all-targets -- -D warnings`, both guard scripts, `cargo test --lib` (274 passing, up from 273). The new test asserts the preview carries the attribution the client will see and that a contact field holding only spaces does not preview as a contact line. Not covered by tests: the rendered block itself, which is markup. The browser-driven e2e specs are still quarantined, so this needs eyeballing on staging once both PRs are deployed.

longjacksonle added 2 commits

2026-08-09 19:28:38 +02:00

feat(forms): let a form carry contact details for the client to use d422d7064a

PMS-748: a request form can now hold a free-text contact line ("the service desk on 555-0100"), shown to the client on the form itself and in the email that links to it, so they can ask before they answer rather than after.

Optional, because the MSP's NAME is shown either way. This is the channel, not the attribution: a form without it is still attributable, a form with it is also answerable.

Both previews carry it, the saved-definition one and the live editor one, so an operator adding a contact line sees where it lands before saving.

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

feat(forms): name the MSP on the client's request form

Check / fmt + clippy + tests (pull_request) Successful in 3m4s

Details

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

Details

4966f9a1ba

PMS-748: the page a client opens from a request-form link showed a title, a set of questions about a named employee, and nothing else. No indication of which MSP was asking, and no way to check before typing a phone number into it.

It now closes with who sent the form and, when the definition carries them, how to reach them. Rendered inside the shared body component rather than around it, so the builder's preview shows an operator exactly what their client will read.

The name suppresses the whole block when empty, which is what a build talking to a server predating this change receives. An empty attribution would otherwise render as a rule above nothing.

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