Events around E-Mails

[pquerner]

Description (*)

Because of PR #1438 I was thinking about having even more events around email, because as of know its difficult (to my knowledge) to disable certain emails from sending out.
For instance I have a client which wants \Mage_Customer_Model_Customer::sendChangedPasswordOrEmail to never fire.

To do this, to my knowledge, you have to extend the full class. Which is ugly and not really that good in my opinion.

Adding more events around emails in the right places (which I currently do not know) would make it easy to disable certain emails from being sent out, right?

Expected behavior (*)

Having events in the right places added.

[rvelhote]

As an alternative, for your consideration, the module aschroder/smtp_pro has many events related to e-mails - you can search for dispatchEvent in the module to see all of them. You also have some additional advantages such as more advanced SMTP/API integration and queueing.

[henryhayes]

You could rewrite the Customer model overwriting just the one method to fire an event, before calling the parent method. Then you could use an observer to do what you're looking to do. It's not all that messy really.

That solves your problem short term. Why not then create a feature request for "customer_email_" prefixed email events... suggesting your then one of us can implement it one go.

Example:

Mage::dispatchEvent('customer_email_password_or_email', array(
   'model'    => $this
));

[pquerner]

You could rewrite the Customer model overwriting just the one method to fire an event, before calling the parent method. Then you could use an observer to do what you're looking to do. It's not all that messy really.

That solves your problem short term. Why not then create a feature request for "customer_email_" prefixed email events... suggesting your then one of us can implement it one go.

Example:

Mage::dispatchEvent('customer_email_password_or_email', array(
   'model'    => $this
));

Maybe I didnt explain myself correctly or I didnt fully understood your answer.

When implementing your solution and listening to this new event, how would I "break" that email from being sent out? Either its a direct die() (not good), or force the email recipient to be null (when magento will throw an exception - which is basically a "cant send" - which then have to be catched elsewhere correctly.

Currently we "break" the email from sending out, by simply overwriting that class, and that method and having the methods body "do nothing". Basically get rid of all logic.

With having email events at the crucial paths (like that external module aschroder/smtp_pro) is doing), you "can" I guess stop it? (Again, by manipulating the crucial parts of a email, like setting the recipient to null)

But is that "a good" approach?

I was thinking more like having the event actually transport a stopExecuting flag of some sort - which will then be processed.