Refactor email templates to better support discovery, reuse and documentation

[NateWr]

Describe the problem you would like to solve
Journal managers want to be able to configure email templates to support a wide range of needs throughout the applications. These include:

• Define when custom templates are/aren't available for use.
  • [OJS] How to change email template management  #3523
  • [OJS] Allow prepared email templates to be selectively available for discussions and participant assignment #3193
• Have a documented glossary of what variables are available and when.
  • Glossary of e-mail variables #3253

Describe the solution you'd like
We'll need a list in the application that defines each possible event that results in an email, and this must be hooked so that plugins can add their own events. Each event can define what variables are available in the email template.

Email templates, including the default templates, should define which events they can be used for. This should be configurable for custom templates but not for default templates, so that journal managers can not accidentally configure no templates for an event.

With this information, it should be possible to accomplish the following:

• Filters in the email templates list for workflow stage or event that allow managers to quickly find the email template they want.
• The ability to call up a list of valid templates for each email event, such as a new discussion, request for revisions, etc. And then let the user select from the allowed templates.
• The ability for journal managers to configure which templates are valid for which events.

As part of longer-term refactoring, it probably makes sense to refactor this so that it is distinct from the Notification and NotificationManager classes that exist.

It may also be worth investigating Laravel's Notification system to see if it might replace our existing system or inspire our refactor.

Who is asking for this feature?
This is a requirement to implement some of the features described above, which have been requested by community members and PS.

Pull Requests
See comment:

• pkp/pkp-lib#5716 Add new manage emails UI and remove email templates … ui-library#227
• pkp/pkp-lib#5716 Add new manage emails UI and remove email templates list  #8407
• pkp/pkp-lib#5716 Add new manage emails UI and remove email templates list ojs#3609
• pkp/pkp-lib#5716 Add new manage emails UI and remove email templates list omp#1242
• pkp/pkp-lib#5716 Add new manage emails UI and remove email templates list ops#387

[ajnyga]

Not sure if this is included in the suggestions above. But the list should somehow show which templates are used based on chosen settings. For example if one-click is enabled, only some of the review templates are used (should we combine some of those templates is of course another question).

[NateWr]

The following are some preliminary mockups of how the new email management UI will work.

Manage emails

This looks similar to the existing email templates UI, except it only lists email events. For example, a single email is shown for "Submission Accepted", but the editor will be able to assign more than one email template to use for that event.

Emails with just one template

When an email is sent automatically, the editor doesn't have an opportunity to edit the email or select a different template. In such cases, the email will only have one template. The edit button will open a modal to edit that template.

(Some emails the editor can edit will still only support one template until we can refactor them.)

Emails with many templates

When editing an email that the editor previews and edits, such as when recording an editorial decision, they can edit the default template and create custom templates. See a mockup of the new Load Template UI when writing an email.

Email template variables

When editing an email template, the user will be able to see all of the variables they can use.

[NateWr]

@asmecher it was a little bit messy because the same code is used for installing and migrations. For minimal impact, I just duplicated some code into Installer.php and then into the individual migrations. See a8bfeae and pkp/ojs@643e979.

[NateWr]

🎉 All merged. Thanks for all your work on this @Vitaliy-1!

[NateWr]

I forgot to add a migration script to upgrade.xml. The following PRs add this:

• pkp/pkp-lib#5716 Add missing upgrade migration ojs#3652
• pkp/pkp-lib#5716 Add missing upgrade migration omp#1272
• pkp/pkp-lib#5716 Add missing upgrade migration ops#408

[NateWr]

All merged.