jlbooker
commented
11 years ago Features I'd like to see in this (for use in other modules):
- An audit log of every message that's been sent, with date/time, sender, recipient(s), subject, and message content. This should be viewable by per user ("What emails have we sent Jeremy?"), per module, and per sender ("What emails did Jeremy send out today?").
- Ability to resend a message later.
- A template editor with template messages. Allow developers to provide logic (by extending a class) for the contents of message. The logic should provide a list of template variables. Allow the user to edit the corresponding message template and insert the provided variables however they'd like. The software can then use this template to send messages.
- Ability to queue messages for later delivery. A module should be able to generate a large batch of emails, but not have them sent right away. This gives the user a chance to review the audit log (as mentioned above) and cancel the messages if something doesn't look right.
I would like there to be a full-featured email system that modules can use. It should be convention that all modules use this system to SEND emails. It should be able to be configured to also RECEIVE emails and report on bounces and failures, both in a single administration UI as well as something that is accessible by the module that sent the mails.
Email has a Message-ID field built-in that should be put in a database table so that we can track the emails that have been sent. Be aware that we can never guarantee that an email was received, but we CAN notify the user if an email was NOT received in many cases.
This sort of fuzzy not-really-guarantee is pretty easy to implement. If the end-user chooses NOT to configure an email account for phpWebSite, as I suspect will be the default and will be the case for many single-instance installations out there, we simply get no error notifications. The UI should specify that we're not LOOKING for error notifications, but that's really all you have to change about it if receiving mail is not configured.
Additionally, I recommend moving to SwiftMailer for all email sending. We should wrap this with our own system in such a way that if the library becomes unmaintained, we can swap it out with something else. In fact, given that email is so well-defined, we can probably give the user their choice of libraries, but we should probably only distribute SwiftMailer ourselves and someone else can implement their own if they'd like.
┆Issue is synchronized with this Asana task