Implement e-mailer with events

[schmunk42]

• simple object/component which hooks into the module events
• use the Yii 2 mailer interface
• easy to customize

[kartik-v]

Extending on this thought... how do we handle e-mail exceptions/failures/errors? Currently there is no option for a newly registered user to get activated, if he does not receive an activation email, due to some error. I have found most user modules do not address this by default.

Solutions/Approaches:

1. QUEUING: Offer a simple db queue to enqueue mails. Based on a module level setting, an email for activation or recovery can be chosen to be enqueued or sent directly. In either case, mails not sent will be available in the db queue with reason for failure. Admins can read this queue through an UI and take action or developers can also create a cron process to read this queue for batch email processing if needed. IMO, we should offer an option for this.. it requires an additional table with few fields.
2. EVENTS: Just give options to developer to add in own code for mail processing, without changing the controller actions or models.

[schmunk42]

It depends on the cause.
If the user mistyped his email it is OK not to activate the account. Some cases are even covered by the e-mail validator.
If we have an error in our code, well - we should test it before.

But we may also add a functionality to resend an activation email and to test the email functionality in general.

I just found out, that the event case is covered by some sample code in the docs...
https://github.com/yiisoft/yii2/blob/master/docs/guide/events.md#triggering-events

I think it would be also pretty easy to use a queue with the event system. In fact, that's another reason for using events, since what happens after registration, activation, etc ... may be so complex.

[kartik-v]

The email sending errors could also be due to email server issues at that point, (due to system load, smtp timeout, or someone is using a third party service that is down at that point).

The use case is - the user may have registered with a genuine email - but he/she did not receive the activation email. The system would also have generated an activation key internally - but we have no way to validate it or send it to the user.

Queuing will offer an option to trace and retry such situations.

I agree, we could combine both the queue with event system as you said.

I will come out with a simple queue structure (which would be an optional plugin to this and enabled by default). You may wish to enhance this with the event system you proposed.

[kartik-v]

Queue structure is now available in the MailQueue model.

[evercode1]

Just wanted to make sure I understood something. I'm assuming in Module.php that:

$this->registrationSettings += [
...
'autoActivate' => true,
...
];

If this is set to true would mean that they do not need to confirm by email to be made an active user? Sorry if it's an obvious question, just checking, thanks.

[schmunk42]

I think it depends on what you want.
I saw some sites where you've registered and you were instantly able to start using the application.
This is the "loosest" validation. Another one would be to auto-login the user after he has confirmed the e-mail address. The most strict validation would be to manually activate the user after reviewing his credentials.

[schmunk42]

@kartik-v Could you explain a bit, why do we need a mail queue table? Is it mainly for logging?
https://github.com/communityii/yii2-user/blob/master/migrations/m140402_143411_create_user_module.php#L98

If you have a component in your application which handles a mail queue, we can hand over the sending of a mail to the component. The only problem I see so far is how to return the result of sending the e-mail to the user module, when it is queued or delayed, I think we need an API for that (but maybe not in release 1.0)

[kartik-v]

@evercode1: If this is set to true would mean that they do not need to confirm by email to be made an active user?

Yes that's correct and as @schmunk42 elaborated

@schmunk42: Could you explain a bit, why do we need a mail queue table?

Usage is planned to be like below:

• Any notification will be first queued in the mail queue table. Method: enqueue()
• Currently module supports notifications for 2 situations: activation and recovery. There will be views created as mail templates for these.
• If user is to be notified instantly - the enqueued mail will be processed and sent. Method: send().
• If there is any error in previous step - the queue status will be updated to error.
• Module settings will have mailDelivery setting which can have these options:
  • ENQUEUE_ONLY: Just enqueue the mail and let developer decide for his app when and how to send.
  • MAIL_ONLY: This will behave like the default advanced app - mail instantly but not enqueue any mails. In this case, no history will be maintained and no mailqueue functionality will be available.
  • ENQUEUE_AND_MAIL: Will do both of the above. This will be the default setting.
• Admin GridView to control the queue table with action mailqueue/index. Admin can filter notifications by status.
• Manually resend or process any mail queue with action mailqueue/resend
• Static batch methods/actions for admin / cron:
  • processErrors: to process all errored mails in the mail queue.
  • purgeHistory: to delete all outdated queue items
• events can be triggered ON_ENQUEUE, ON_ERROR, ON_SEND

The key advantages:

• ensure there is an easy method for managing failed notifications and assure delivery of a critical message to the user
• allow user or admin to resend an activation/recovery notification
• automating notifications to be processed the way one wants for his app.
• allow the developer to use the mailDelivery setting to control how and when to notify users
• this mailqueue can be extended for other non-email (e.g. mobile text message / other instant message) channels by developers easily