Add support for custom Jinja2 email messages

[rl-utility-man]

specific projects will need custom welcome messages. add yaml config to customize the new account created email message. consider using e.g. Jinja tags for things like {{username}} and {{password}}

[janoskabedis]

The tags are a good idea. This is reasonable. Are you wedded to using YAML? Or would plaintext make sense.

Or ... and maybe this is just me wrapping my head around how you think we should make emails customizable ... is the idea that we add email customization to forms (email_text_on_creation, email_text_on_update, etc.)? Or, a central hub for defining emails more generally. Obviously, some mix is needed because the goal is to also add custom welcome emails, and these are not linked to the form config at all.

[rl-utility-man]

I'm not wedded to YAML. Indeed, I think a pretty general solution is desirable: the more that this project is an efficiently customizable workflow management system, the more useful it will be. For example, we may want to generate custom reminder emails or custom emails that describe the concerns a reviewer had. If the system can provide email templates in a way that is as easy and flexible as its tools for creating forms, and we can weave email and web together, it will be extremely powerful. To my mind, Jinja is a more logical starting place for an email template than is YAML

[signebedi]

Great, I'm starting to see the vision. Now that we talk through it, maybe yaml+jinja2 makes sense. So... Maybe we create an in internal event mapping:

{
  "user_creation": {
    "subject": "some subject",
    "content": "Some Text with {{jinja}}",
    "cc_addresses": ['[email protected]']
  },
  "form_creation_<form_name>": {
    "subject": "another subject",
    "content": "More Text with {{jinja}}",
    "cc_addresses": ['[email protected]']
  },
}

This could be managed in its own (yaml? for the purpose of consistency) config and edited in the UI?

Alternatively, we could write these to the relational database as their own table, like email_overrides or something. These could still render jinja2 on read...

[rl-utility-man]

This all makes sense to me. Maybe allow the user to configure the sender name and email address

Consider having some notation like email names that start with _ are potentially reserved email names like _user_creation, while email names without that notation are available for custom programmed emails like:
first_reminder, upcoming_deadline, management_approval, management_revision_request, core_team_approval, etc.

Similarly, we might want to have some notation for reserved jinja variables, like {{ _user_name }} and {{ _form_name }}

Would we want a more conventional email interface that allowed non programmer admins to send one time blasts to selected groups of users?

[signebedi]

I've added some preliminary code. It only renders defaults and requires us to define more logic in order to override defaults with our own, custom jinja subject and content. But, this is a start. My next step is to propagate this logic throughout the fastapi application. This will effectively bifurcate email subjects and content from the app itself, instead passing as many context variables to the renderer as possible to give us the widest flexibility in creating emails. However, it's important to note that not ALL context will be available for ALL emails. For example, form_name will not be available when we are sending registration emails...

[rl-utility-man]

This sounds great. The nature of the system is that not every potential context variable will be defined in every system context and that not every email template makes sense in every system context. So long as we throw helpful errors in the UI, build good testing tools for developing automated messages, and notify automated job owners when automated messages do not go out, we're good. Some kind of context concept that specifies that an email would go out only if the accompanying preconditions are met and prevents us from putting nonsense email configs into production might be even better.

[signebedi]

I think that a good way to do this is to run a test-on-config-change for the emails. That is, when emails are changed, attempt to render them all with the appropriate context placeholders that each can expect.

Another way could be to add visual cues with the available context, and to add it into the docs, too.

[signebedi]

Add submission content as context for form-related email templates
We may want the full form details available to emails when they are sent out. As such, we should rework this to be a little more flexible in the context that is available for form-related emails. Especially true once we add #210, which will be far more powerful and may require us to rework emails to be able to also specify recipients and CC addresses.

[signebedi]

This base feature has been added. More work is needed to verify the stability of the feature and document the context variables available, and to further refine the context variables available to provide the appropriate amount of information for emails. This is an iterative process, and some of it can be tracked in #311 or future bug reports / requests. Closing this issue for now.