08-Jun-2026 — email wording moved from Brevo into the website, editable by groups #273

Delivered in commit 10c1d92.

A step-by-step user guide with screenshots for these changes is available at Customising Email Wording.

In plain English

• The website sends a number of emails automatically: a welcome email for new members, login details, password resets and booking confirmations. Until now, the layout and wording of these emails was stored in Brevo, the email service that delivers them. Changing them meant using Brevo's own editing tool, which could quietly break the personalised links inside the emails. It also required that the user had to log into brevo, which had his own username and password and also learn how to navigate around that system and edit content in the Brevo way.
• The wording and a pretty smart message templating mechanism (think of a modern-day mail merge), is now built directly into the NGX-Ramblers. Every group gets the same well-tested emails, and improvements arrive automatically with each new release, with nothing for groups to set up or copy across.
• Committee members can change the wording directly on the website under Mail Settings, using an ordinary editor: no HTML and no Brevo account needed. Whole emails can be reworded, and booking emails can be adjusted section by section, where each section can keep the standard wording, use your own wording, or be left out.
• Anything a group has customised is kept exactly as written, even when the standard wording is improved later.
• Brevo still delivers the emails, but it no longer has any say in how they read or look.

Why this was needed

Branded emails were already rendered by the website's own code, but the HTML was fetched from templates stored in Brevo. Editing those templates in Brevo's WYSIWYG editor URL-encoded the merge-field tokens inside links, which broke the server-side substitution and produced dead password-reset links (See ticket #212). The forgot-password email had already been moved onto a local file; this release completes the job for every branded email.

Templates are now part of the website

Each notification config names a template file held in the code repository, via a new templateName field. Rendering always uses that local file. The old templateId field, the render-time fetch from Brevo, the Brevo template picker in Mail Settings and the related admin tooling have all been removed. Brevo's only remaining job is delivering the emails, so nobody ever needs to login there now.

Content blocks

Templates can declare named sections using {% block %} markers. For each section, a group can keep the standard wording, supply its own wording, or leave the section out, and these choices are stored on the notification config as typed overrides. The welcome and login-details emails and all five booking emails (confirmation, cancellation, waiting list, restored, reminder) use this mechanism. Booking emails also gained proper merge fields (attendee name, event title, date, places booked) in place of the old bespoke placeholders.

Email body editor

Configurations that are not block-based get a single-document editor in Mail Settings: rich text with merge-field insertion, internal page links, image embedding, and a reset-to-default option where a standard template exists. A toggle records whether the body is written in the configuration or supplied by the Email Composer at send time, and switching between the two never loses work. Bold and italic are now saved as HTML rather than markdown, which fixes the stray asterisks that previously appeared around bold labels and merge fields.

Migrations and tests

Existing notification configs were given the right templateName automatically based on their subject, image overrides were converted to the new typed shape, and any custom site-level or per-event booking templates were moved onto content blocks. New tests lock in that the welcome and login-details emails render from the repo files with the password-reset link intact.