Test Monitoring Mail with real examples

From comment #22 in the parent issue:

I've just updated/applied the monitoring RRD patch #18, set the recipient as my private gmail address in the monitoring settings, and ran a critical sensor (/admin/reports/monitoring/sensors/core_requirements_system), then checked my mailbox and i get the mails.

So somehow, sending mail is working (but changing subject value, will create a different thread), that probably means that in the monitoring_rrd patch we are doing something that here is missing, need to learn this deeper...

@Ginovski just tried the same on his machine (ubuntu) but he doesnt get any mail... dont know what to think now...

Discussed with @miro_dietiker this morning and a "nice-to-have feature" is to group the messages in a thread per sensor but change the subject to display the new status and a sensor ID (as a short description/quick preview of the mail), but according to different sources.

Gmail API:

In order to be part of a thread, a message or draft must meet the following criteria:

1. The requested threadId must be specified on the Message or Draft.Message you supply with your request.
2. The References and In-Reply-To headers must be set in compliance with the RFC 2822 standard.
3. The Subject headers must match.

(source: https://developers.google.com/gmail/api/guides/threads)

StackExchange:

a conversation will break off into a new thread if the subject line of the conversation is changed, or if the conversation reaches over 100 messages.

(source: http://webapps.stackexchange.com/questions/965/how-does-gmail-decide-to-...)

So it looks like it is not possible to change the subject value but appending the new mail in the same thread :/

Trying to work on top of #2788041: Implement Message-ID and Reference in mail header to build per-sensor thread patch #34.
Moved some changes made there trying to keep the scope, so here we can focus improving the UX and improving our mail test handling Gmail threads (for now).

From the feedback in the other issue at comment #31:

2.

+++ b/modules/monitoring_mail/monitoring_mail.module
@@ -11,56 +16,62 @@ use Drupal\monitoring\Result\SensorResultInterface;
   // Set the mail subject.
-  $status = $result->getStatusLabel();
-  $subject = strtoupper($status) . ': ' . $result->getValue() . ' ' . $sensor_config->getLabel();
+  // According to the Gmail API, the subject needs to be static to make mails
+  // of the same sensor to be grouped in the related thread.
+  // See https://developers.google.com/gmail/api/guides/threads
+  // @todo check how the other mail accounts handle threads.
+  $subject = '[' . $site_name . ' - MONITORING] ' . $sensor_config->getLabel();
   $message['subject'] = $subject;

that however means that it is no longer possible to see in a mail subject if it is now failing or not.

Not sure if that isn't a bigger downside than being able to group them?

We tried to figure out the easiest way to have a sensor mail "failure/success" visible at "first sight/quick visualisation" and we ended up to show the new sensor status as the sender target's phrase (human comprehensible name), but I've noticed that the "senders column" is slightly different between the browser and mobile inbox UI versions:

Browser:

Mobile:

In addition, I thought to put the "status changed" at the top of the body so that it could be visible as trimmed preview mail text when you see the inbox overview.

5.

+++ b/modules/monitoring_mail/monitoring_mail.module
@@ -11,56 +16,62 @@ use Drupal\monitoring\Result\SensorResultInterface;
-
-  $body[] = 'Status: ' . $status_old . ' > ' . $status_new;
+  $body[] = 'Result message:<br/>' . $result->getMessage();
   $body[] = '';

isn't this a plain text mail? using <br/> is strange, I guess it will get converted to newline but lets just use a newline from the start.

I've just seen it had too much space between the "short description" and the "sensor result message text":

but yes, just removing a $body[] = ''; was enough.

A bug has been found: a result is/is not logged based on status change, but to send a mail we always checked with the second last sensor result which could be/not be outdated (as we store the current result as the "last sensor result" if the status changes).
Added a setter/getter to set the previous result when we want to log the current one, so we don't get the wrong result and don't need to fancy store the previous status to check if a mail needs to be sent.

Test fails --> waiting for the parent issue to be committed.

Btw, with these new setter/getter methods, I've noticed that mails are sent slightly slower than before...

Removed some code to the followups:
- hook_requirements: #2800051: Implement hook_requirements() for monitoring_mail recipient
- bugfix: #2800055: Get the correct previous sensor result

Threading part will be improved here, as well as the test/assert methods.

Miro wants to review and test to define the goals of this issue and how we deal with threading.