Log a message to the order activity when the order receipt is sent

1. +++ b/modules/log/commerce_log.commerce_log_templates.yml
   @@ -27,3 +27,11 @@ order_assigned:
   +order_mail_success:
   +  category: commerce_order
   +  label: 'Mail successfully sent'
   +  template: '<p>Mail "{{ id }}" successfully sent to {{ to_email }}.</p>'
   
   +++ b/modules/log/src/EventSubscriber/MailEventSubscriber.php
   @@ -0,0 +1,58 @@
   +    $template_id = (bool) $message['result'] ? 'order_mail_success' : 'order_mail_failure';
   +    $log_params = ['id' => $params['id'], 'to_email' => $message['to']];
   

   We could provide specific logs for known email key IDs and fallback to this if none exists.

   Maybe follow a pattern of `mail_${key}`? That way users can also provide log templates for custom emails they send through our mail handler.

   So provide a default `mail_order_receipt`, then someone could provide `mail_order_shipped` if they send an `order_shipped` email through our service (I currently do this.)

   So we can check if the definition exists and use that or the fallback for the SUCCESS, and the generic failure on any failure.

2. +++ b/modules/log/src/EventSubscriber/MailEventSubscriber.php
   @@ -0,0 +1,58 @@
   +class MailEventSubscriber implements EventSubscriberInterface {
   ...
   +    if (!isset($params['order']) || strpos($params['id'], 'order_') !== 0) {
   +      return;
   +    }
   

   This only handles order mail, so maybe we should rename it as such?

3. +++ b/modules/log/src/EventSubscriber/MailEventSubscriber.php
   @@ -0,0 +1,58 @@
   +  /**
   +   * The log storage.
   +   *
   +   * @var \Drupal\commerce_log\LogStorageInterface
   +   */
   +  protected $logStorage;
   ...
   +  public function __construct(EntityTypeManagerInterface $entity_type_manager) {
   +    $this->logStorage = $entity_type_manager->getStorage('commerce_log');
   

   I've stopped grabbing entity storage in constructors, as it adds a little bit of overhead fetching the storage when it may not be used.

   When collecting event subscribers, this will always be constructed and always fetch and instantiate the log storage.

🥳 looks great to me, this will definitely help customer support users

I like the idea of logging failures, but it may be confusing what success or failure means in this context. A log message of:

Order receipt email sent to @mail (Result: "failure").

Makes me wonder why the log says it was sent if the result was a failure; did it actually send? was the failure a lack of receipt by the customer? an error from an external email service? In reality, it just didn't send. I'm open to suggestions, but it seems better to have:

Order receipt email sent to john.doe@example.com.

Order receipt email failed to send to john.doe@example.com.

The problem is that seems to violate the expectation of log message templates. I can't tell if we'd have to register two templates per mail (successful send vs. failure) or perhaps just implement a single failure template for any email:

Failed to send [email type] to john.doe@example.com.

Using a specific template for failures may make it easier to add contextual links to log messages in the future (e.g. a link or button to attempt to redeliver that email in the stream), though I'm dependent on you to know what's really possible there.

Looking good to me.

+1

🥳 Committed!