fix(notifications): reseed the 023 templates and report unresolved keys #470

Merged

Claude-Run merged 1 commit from fix/PMS-702-reseed-notification-templates into main

2026-08-01 02:26:11 +02:00

Claude-Run commented

2026-08-01 02:16:05 +02:00

Member

Migration 023 seeded eight notification templates that could never render. The bodies were plain single-quoted literals, so with standard_conforming_strings on every \n was stored as a literal backslash + n and the mail would arrive as one long line, and every placeholder was dotted ({{ticket.number}}) while render_template resolves flat top-level context keys only and re-emits unresolved braces verbatim. Migration 021 already documents both requirements.

Migration 096 rewrites those rows in place with E'...' literals and flat keys (ticket_number, company_name, invoice_total, ...) that follow the existing ticket.note_added context. 023 itself is untouched: migrations are immutable and editing an applied one makes deployed databases refuse to boot. Each UPDATE is guarded on the dotted placeholder still being present, so an operator-customized row is left alone and re-running is a no-op.

render_template now returns the de-duplicated list of keys it could not resolve and dispatch warns on any, so a future template typo shows up in the logs instead of in a customer's inbox. The rmm alert-title renderer keeps its existing behaviour.

A new #[sqlx::test] in tests/notifications.rs scans every migration-seeded template and fails on a literal backslash-n or a dotted placeholder in any subject or body, so neither defect can come back.

#PMS-702

Migration 023 seeded eight notification templates that could never render. The bodies were plain single-quoted literals, so with standard_conforming_strings on every `\n` was stored as a literal backslash + n and the mail would arrive as one long line, and every placeholder was dotted (`{{ticket.number}}`) while `render_template` resolves flat top-level context keys only and re-emits unresolved braces verbatim. Migration 021 already documents both requirements. Migration 096 rewrites those rows in place with `E'...'` literals and flat keys (`ticket_number`, `company_name`, `invoice_total`, ...) that follow the existing `ticket.note_added` context. 023 itself is untouched: migrations are immutable and editing an applied one makes deployed databases refuse to boot. Each UPDATE is guarded on the dotted placeholder still being present, so an operator-customized row is left alone and re-running is a no-op. `render_template` now returns the de-duplicated list of keys it could not resolve and `dispatch` warns on any, so a future template typo shows up in the logs instead of in a customer's inbox. The rmm alert-title renderer keeps its existing behaviour. A new `#[sqlx::test]` in tests/notifications.rs scans every migration-seeded template and fails on a literal backslash-n or a dotted placeholder in any subject or body, so neither defect can come back. #PMS-702

Claude-Run added 1 commit

2026-08-01 02:16:05 +02:00

fix(notifications): reseed the 023 templates and report unresolved keys

E2E / Playwright against staging (pull_request) Successful in 47s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 2m16s

Details

Integration / integration tests (pull_request) Successful in 9m48s

Details

Create release / Gate (release-branch merges only) (pull_request) Successful in 1s

Details

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

Details

f646985fad

Migration 023 seeded eight notification templates that could never render. The bodies were plain single-quoted literals, so with standard_conforming_strings on every `\n` was stored as a literal backslash + n and the mail would arrive as one long line, and every placeholder was dotted (`{{ticket.number}}`) while `render_template` resolves flat top-level context keys only and re-emits unresolved braces verbatim. Migration 021 already documents both requirements.

Migration 096 rewrites those rows in place with `E'...'` literals and flat keys (`ticket_number`, `company_name`, `invoice_total`, ...) that follow the existing `ticket.note_added` context. 023 itself is untouched: migrations are immutable and editing an applied one makes deployed databases refuse to boot. Each UPDATE is guarded on the dotted placeholder still being present, so an operator-customized row is left alone and re-running is a no-op.

`render_template` now returns the de-duplicated list of keys it could not resolve and `dispatch` warns on any, so a future template typo shows up in the logs instead of in a customer's inbox. The rmm alert-title renderer keeps its existing behaviour.

A new `#[sqlx::test]` in tests/notifications.rs scans every migration-seeded template and fails on a literal backslash-n or a dotted placeholder in any subject or body, so neither defect can come back.

#PMS-702