External email handler for user notifications

Contribute Feature

AI-generated summary

The discussion revolves around implementing an external email handler for user notifications in Discourse. sniepoort proposes a feature that would allow administrators to control email notifications by enabling or disabling the Discourse email handler and instead using an external service like Postmark. This would provide more flexibility in customizing email templates and allow for mapping of available fields to the template model.

LeoMcA suggests that this could be achieved through a plugin, which could monkey patch the relevant methods to enable or disable the Discourse email handler. They also recommend designing the plugin to support multiple APIs, with a setting to choose the API to use, making it easier for contributors to implement support for different email APIs.

1

This is a feature request, but also something that could be suitable for a plugin - where we would like some guidance/input.

Basically, we feel that there isn’t enough control over email notifications that are sent out to users, both in deciding which to send, but also the actual templating. We are aware that email templates are customisable, but we feel it’s a bit limiting. We can’t for example style anything that goes on in {message}. That isn’t to say Discourse doesn’t have a pretty solid emailing system, but it has it’s limits.

Therefore, it would be really nice if we could have the option of handling anything email related over to a external service, such as Postmark.
This module would for example list all available email types (user_posted, user_private_message, user_invited_to_topic, etc.), and you would have the option to enable or disable for the Discourse email handler. If disabled, you would then be given the option to post it to an external api like Postmark, defining which template to use, and mapping available fields (like user, post, etc.) to the template model.

We’re aware that this is pretty library specific (the Postmark API obviously varies from others), but perhaps a solution could be found for a general use case. Again, we’re interested to hear any thoughts.

2

Just my £0.02:

My thoughts are this wouldn’t be terribly hard from a plugin - one could monkey patch all the appropriate methods, and then based on whether the setting is currently to have the Discourse email handler enabled or not, call super within the patched methods, or call your own code.

I think the best way would be to write the plugin with the assumption that other APIs will be supported (so, for instance, include a setting to choose which api to use, and therefore write all the code to work based on what that setting is set at), but not necessarily implementing any of them. Then, it should be trivial for another contributor to implement support for whatever email API they want to use, and send a PR.

2 curtidas