Editable mail templates

[JornWildt]

Using static files for mail templates, as described in https://www.cofoundry.org/docs/framework/mail, requires a programmer to change the template content. I would rather make it possible to edit the templates through the admin interface - and have a standard way of doing that.

I'm going to add that myself using the standard custom entity system - having a new MailTemplate custom entity with a standard title, standard HTML template content and a user supplied identifier string such as "WelcomeTemplate" or "ConfirmationTemplate".

With that I can add a system for finding specific custom entities by the identifier, merge relevante text into them using $$ placeholders with StringTemplate (https://www.nuget.org/packages/StringTemplate4) - and then send them with Cofoundry's built-in mail framework.

Could be nice to see such a thing as a built-in thing :-)

[HeyJoel]

It sounds like you're wanting to add content management to pre-defined templates? E.g. in code you could define a welcome template (like you do a page template), but you want to be able to customize the messaging in that template? Or is it a case that you want full control of the HTML in that template?

The tricky thing with emails is that to code reliable HTML emails it's best to use a pre-processor like Foundation for emails, and so I've always seen them as something that's developer defined, and therefore defined in code, but the boundaries are often blurred and I'm interested in understanding whether this would be a developer convenience UI or if this is for user editing.

In any case, I think it's cool that you can use the Cofoundry building blocks to create what you need here, that's the sort of composability we're aiming for.

[JornWildt]

My use case is a booking system for a lodge. When someone submits a booking request, the system replies with a receipt e-mail. When the administrator confirms the booking, the system sends a confirmation e-mail to the contact person. Further steps involve more e-mails.

These e-mails could surely be defined by a developer, for the good reasons you put forth.

But the e-mail text is also a kind-of living thing that should be easy to modify without involving developers. Telephone numbers may need to be changed, spelling fixed, new administrator names added in the signature and so on. Calling a developer for these issues is just as impractical as calling a developer for changing text on the website itself. The text is owned by the business side and as such they should be able to change it.

Further more, the auto generated mail body is presented to the administrator for editing before sending. So for instance:

1. Admin confirms a booking.
2. System generates a confirmation mail with contact person's details merged in.
3. System redirects to a page where the admin can edit the HTML text before sending it, so that customer specific details can be inserted (should it be needed).
4. Admin edits the text and press "Send".

This is by the way also the reason for this question here: https://stackoverflow.com/questions/66813910/is-there-a-way-to-reuse-the-built-in-html-editor-in-cofoundry 😉

[JornWildt]

The templating system turned out to be surprisingly simple to implement using the building blocks from Cofoundry. You can see it here https://github.com/Bogevang-spejderhytte/website/tree/main/Bogevang.Templates.Domain

Kudos for a very well designed and well structured framework 👍

[HeyJoel]

Ok great, so it sounds like the idea of having content-managed email templates, where the template is defined in code but certain elements can be content managed, which I think is interesting.

It's worth noting that I think most email providers (e.g SendGrid) have some kind of templating system that you can also use to achieve similar things, and they will probably be better at doing it due to the complex and evolving way emails work. So that's something to consider.

In terms of your workflow, I just think we need to be better at providing the building blocks that enable you to create those workflows.

[JornWildt]

Ok great, so it sounds like the idea of having content-managed email templates, where the template is defined in code but certain elements can be content managed

Yes.

For the current solution I use the Cofoundry "slug" to identify the templates. So "defined in code" only means that the code defines the required slug and then the admin has to remember what slug to use (and avoid changing it).

[JornWildt]

Thinking of it - it seems as if it is a variation of "singular admin entities" as discussed in #243.

Defining a singleton custom entity "Confirmation e-mail" with an HTML property should work also. Then the developer could define all these different mail templates in code as singleton custom entities where after they would be available in the admin interface.

But currently I prefer the "slug" reference. It has the added benefits of allowing admins to experiment with different templates just by renaming the slug.

And ... having said that ... it might be even better to simply have a C# enumeration for { Receipt, Confirmation, Payment, Thanks } and then make that editable on the template custom entity. Then the admin wouldn't have to remember those identifiers - at the price of being unable to reuse the templates in other scenarios 🤔 The enumeration could even be a another custom entity(!) 🙈 choices, choices, choices ...