Ensure last_email_run gets initialized

[stephen-cox]

Fixes #92

[graham-web]

Minor thought... shouldn't it also reset the last_email_run state when the "Enable email notifications" box has become ticked? Else the user would receive a flood of old notifications as soon as they [re-]enable e-mails!

Or perhaps simpler, for the same effect, just update state every time within hook_cron during the early-return?

[ekes]

Else the user would receive a flood of old notifications as soon as they [re-]enable e-mails!

Reading the code what gets sent by the module is base on querying using the REQUEST_TIME

localgov_workflows/modules/localgov_workflows_notifications/localgov_workflows_notifications.module

Line 133 in 94dad59

$request_time = \Drupal::time()->getRequestTime();

and

localgov_workflows/modules/localgov_workflows_notifications/localgov_workflows_notifications.module

Line 143 in 94dad59

->condition('review', $request_time, '<=')

iff the run should happen based on the last run value

localgov_workflows/modules/localgov_workflows_notifications/localgov_workflows_notifications.module

Line 136 in 94dad59

if ($request_time >= $next_run) {

So the number of mails should be the same no matter what?

Ahh

localgov_workflows/modules/localgov_workflows_notifications/localgov_workflows_notifications.module

Line 142 in 94dad59

->condition('review', $last_run, '>')

OK I'd say another issue for that.

[stephen-cox]

It's probably a good idea to reset the last_email_run state var when turning email sending on.

This would bring in quite a bit of duplication of code when resetting the the var, so I'm thinking of abstracting this into a service to make it easier to test.

Given this is quite critical, I suggest merging this and creating a new issue for reseting the var when enabling email sending.

[finnlewis]

Discussed at Merge Tuesday. Thanks for your comment @graham-web - we've created a separate issue to deal with that. #94

Otherwise, we're happy to get this out to councils who are testing.