The content billing's four financial emails fall back to.
Until now these lived in phoenix_kit_emails, seeded into the
phoenix_kit_email_templates table — so the emails package hardcoded another
module's copy, and billing could not send at all without it installed. That
table is being retired; this is where the content lives instead.
Handed to PhoenixKit.Mailer.send_from_template/4 as :defaults, which
resolves in order: an active database template, then a host override file for
the recipient's locale, then this. A host that customized one of these
templates keeps its customization — the database still wins — so adopting
this changes nothing for an existing install.
Why these are functions, not a map
send_from_template/4 evaluates a zero-arity :defaults inside the
recipient's locale. A map would have been evaluated in whatever locale the
caller happened to be in — which, on a background job sending an invoice, is
nobody's.
HTML is deliberately absent
The shipped templates also carried an HTML body: roughly 200 lines each of inline markup, with the header and footer chrome copy-pasted between them. Re-homing that here would bake the duplication into a second package immediately before the shared layout layer is built to remove it.
Consequence, and it is a real one: a host loses the HTML billing emails when the templates table is dropped, keeping the plain-text ones. The layout layer has to land before that drop. Until then nothing changes, because the database row still wins.
Summary
Functions
A zero-arity function returning the default content for name, or nil when
this module has nothing to say about that name.
The template names this module supplies defaults for.
Functions
A zero-arity function returning the default content for name, or nil when
this module has nothing to say about that name.
@spec template_names() :: [String.t()]
The template names this module supplies defaults for.