Email templates are buried in Settings and squeezed into 720px — give them their own Emails tab #135

New Issue

2026-08-23T07:47:00-05:00

bermudalamb commented

2026-08-23 07:47:00 -05:00

The six customer email templates live at the bottom of the Settings tab, underneath the cart-expiry card, inside a maxWidth: 720 wrapper. Two problems follow from that.

Finding them takes knowing they are there. "Settings" reads as app configuration, and the one visible thing on that tab is a 480px card about cart expiry — the email editors are below the fold with no indication from the tab label that they exist at all.

The editor is then crushed. EmailTemplateEditor splits into a markdown editor and a live preview iframe side by side (lg={13} / lg={11}), but the whole thing is capped at 720px regardless of how wide the display is, so each half gets under 350px. The preview pane — the entire reason the split exists — renders the email at a width nothing resembling how it will actually be read, and the markdown editor's toolbar wraps.

Move the email templates out to an Emails tab of their own, immediately to the left of Settings. Inside it, navigate between the six email types with a left vertical rail rather than the current horizontal tab strip: the labels stack instead of wrapping as templates are added, and the editor keeps the full remaining width. Let the whole thing spread to the width of the display area instead of the fixed 720px cap.

Simplify what surrounds the editor while it moves. The Customer emails heading and its blurb become the tab's own context rather than a heading stacked inside a page that already has one, and the Default / Customised antd Tag on every label comes off the rail — a customised type gets a small dot, and the full state stays where it is actionable, next to the Restore default button in the editor.

Settings keeps the cart-expiry card and nothing else.

Acceptance criteria

An Emails tab sits between Customers and Settings in the admin tab strip
Every one of the six templates is reachable from a vertical rail inside that tab
The editor and preview spread to the available width — no maxWidth cap on the Emails tab
A customised template is distinguishable from a default one without opening it
Settings shows only the cart-expiry card
frontend/tests/e2e/email-templates.spec.ts navigates via the new tab and passes

The six customer email templates live at the bottom of the Settings tab, underneath the cart-expiry card, inside a `maxWidth: 720` wrapper. Two problems follow from that. Finding them takes knowing they are there. "Settings" reads as app configuration, and the one visible thing on that tab is a 480px card about cart expiry — the email editors are below the fold with no indication from the tab label that they exist at all. The editor is then crushed. `EmailTemplateEditor` splits into a markdown editor and a live preview iframe side by side (`lg={13}` / `lg={11}`), but the whole thing is capped at 720px regardless of how wide the display is, so each half gets under 350px. The preview pane — the entire reason the split exists — renders the email at a width nothing resembling how it will actually be read, and the markdown editor's toolbar wraps. Move the email templates out to an **Emails** tab of their own, immediately to the left of Settings. Inside it, navigate between the six email types with a left vertical rail rather than the current horizontal tab strip: the labels stack instead of wrapping as templates are added, and the editor keeps the full remaining width. Let the whole thing spread to the width of the display area instead of the fixed 720px cap. Simplify what surrounds the editor while it moves. The `Customer emails` heading and its blurb become the tab's own context rather than a heading stacked inside a page that already has one, and the `Default` / `Customised` antd `Tag` on every label comes off the rail — a customised type gets a small dot, and the full state stays where it is actionable, next to the Restore default button in the editor. Settings keeps the cart-expiry card and nothing else. ### Acceptance criteria - An `Emails` tab sits between `Customers` and `Settings` in the admin tab strip - Every one of the six templates is reachable from a vertical rail inside that tab - The editor and preview spread to the available width — no `maxWidth` cap on the Emails tab - A customised template is distinguishable from a default one without opening it - Settings shows only the cart-expiry card - `frontend/tests/e2e/email-templates.spec.ts` navigates via the new tab and passes

bermudalamb commented

2026-08-23 07:47:16 -05:00

Clarifying questions and answers from the brainstorming pass, recorded here so the decisions are not only in a chat log.

Q: Inside the new Emails tab, how should the per-email-type navigation be laid out — a left vertical rail, or horizontal tabs across the top as today?

A: Left vertical rail. The six email types stack down the left and the editor plus preview take the whole remaining width. It never wraps as templates are added, and it gives the editor a genuinely wide split rather than two ~350px columns.

Q: Each email type currently carries a blue "Customised" / grey "Default" tag on its tab label. Keep it, reduce it, or drop it?

A: Reduce it to a subtle dot on the label. A small dot marks the customised types, and the full state — the wording plus the Restore default button — lives in the editor header where it is actionable. Six tags stacked down a rail is tag-heavy and stops it being scannable, but dropping the marker entirely would cost the at-a-glance answer to "which of these have I changed".

Clarifying questions and answers from the brainstorming pass, recorded here so the decisions are not only in a chat log. **Q: Inside the new Emails tab, how should the per-email-type navigation be laid out — a left vertical rail, or horizontal tabs across the top as today?** A: Left vertical rail. The six email types stack down the left and the editor plus preview take the whole remaining width. It never wraps as templates are added, and it gives the editor a genuinely wide split rather than two ~350px columns. **Q: Each email type currently carries a blue "Customised" / grey "Default" tag on its tab label. Keep it, reduce it, or drop it?** A: Reduce it to a subtle dot on the label. A small dot marks the customised types, and the full state — the wording plus the Restore default button — lives in the editor header where it is actionable. Six tags stacked down a rail is tag-heavy and stops it being scannable, but dropping the marker entirely would cost the at-a-glance answer to "which of these have I changed".

bermudalamb referenced this issue

2026-08-23 08:10:08 -05:00

Make the email settings configurable: token lifetimes, cart hold, and the greeting #136

bermudalamb added this to the Make the password-reset email editable from Admin project 2026-08-23 08:13:58 -05:00

bermudalamb self-assigned this 2026-08-23 08:14:18 -05:00

bermudalamb moved this to In Progress in Make the password-reset email editable from Admin on 2026-08-23 08:16:28 -05:00

bermudalamb referenced this issue from a commit

2026-08-23 08:20:14 -05:00

feat(admin): give the customer emails a tab of their own (#135)

bermudalamb moved this to Review in Make the password-reset email editable from Admin on 2026-08-23 08:20:35 -05:00

bermudalamb referenced a pull request that will close this issue

2026-08-23 08:20:48 -05:00