Templates — admin

Who opens it: an organizer wondering what the emails their registrants get actually say, or an admin who has heard that EntryWick added new ones.

What they came to do: see the copy this organization sends and prints, and get the templates they never received.

True when they leave: every template EntryWick ships exists for this organization, and nothing they had written themselves has changed.

Decisions already made

• One row per kind and code, at its newest version — the version that actually sends. Earlier versions stay in the database because messages.template_version records what each person was sent, but they are not a list anyone needs.
• "Wording" says whose it is: EntryWick default until somebody edits it, then Yours. That is the only thing an organizer needs to know before deciding whether to touch it.
• Sync system templates appears only while something EntryWick ships is missing, and needs templates.write. It adds the missing ones and never changes a code the organization already has, edited or not. The modal lists what it will add before it adds anything.
• A core template the organization deleted comes back through the same action: deleting one and then needing it is exactly what that means.
• Why it exists: a default template reached a tenant only when SystemTemplatesSeeder ran for it — at signup, and never again. Week 12's approval and waitlist emails therefore reached no organization created before them (owner, 2026-09-13), and nobody could ask for them.

Editing, and the starter library (week 22 step 2)

• Edit works on every kind. Until week 22 only a badge or a print sheet could be edited here, so an organization could not change a word of its own confirmation email from the admin at all. Now the modal takes the name, the subject line where the kind sends one, the card size and layout where it prints, and the body.
• Saving writes the next version and moves the schedules. Nothing is overwritten, because a message records the wording it went out with (messages.template_version). Every schedule that can still send with an earlier version moves to the new one — an edited confirmation is what the next confirmation says — and the notification says how many moved. A rename on its own is not a new version.
• Copy that names something that does not exist is refused when you save it, not when somebody receives it. The refusal names the line. "What you can name" under the box is the whole list for that kind.
• Preview renders against a made-up family — the same context the refusal uses, so the two always agree. Broken copy shows its error in the preview rather than pretending. Available from the table and from inside the editor.
• Start from a starter offers copy per kind and per kind of event: the generic wording EntryWick ships, then one shelf per vertical (school field trip, volunteer day, conference, sports tournament, corporate offsite, community celebration). Choosing one previews it before it replaces anything, and nothing is saved until the template is saved.
• The starters are the event templates' own copy, read out of /templates/*.json (StarterTemplates). There is no second copy of a sentence to keep in step. A starter's placeholders are resolved first — an event template says {{ph.office_phone}} until an organizer answers, and Liquid refuses an unknown variable — so anything without a default becomes a square-bracketed prompt like [school office phone], which renders and reads as "fill this in".
• New template makes a new code from a starter. A code that already exists is refused: a code identifies one template and its versions are that template's history, so a second "version 1" would put two templates in one history.

Open questions

• Nothing shows which schedules send a given template, which is the first question after "what does it say?".
• The body is a plain textarea with a monospace font. A rich editor would help the person writing an email and hurt the person writing Liquid; left as it is until somebody asks.