"New Mailing" prematurely schedules blasts and old mailings can be resent
Steps to reproduce
- Open a MySQL console where you can monitor the content of
civicrm_mailing_job
. - Make a
Mailing => New Mailing
- Fill in name/subject/recipients/body on the first page.
- Go to the second page
- Observe: In the MySQL console, observe that there are no jobs scheduled for this mailing.
- Set a delivery time. But don't hit
Submit
. (You're just thinking about delivery... but not actually sending yet.) - Open an HTML or plain-text preview.
- Observe: In the MySQL console, observe that there is now a scheduled job for this mailing.
To resend an old mailing:
- Any mailing will be queued for redelivery if a user with permission to use CiviMail visits URL
civicrm/a/#/mailing/<MAILING_ID>
(we've seen several users end up on this URL, apparently via browser history)
Mitigating factors
The only way I've found to trigger the premature mailing (so far) has been to explicitly set the delivery date. It's quite bad to be sending prematurely, but I think it's taken a while to recognize because the delivery date is the last thing in the entire process -- most of the time, one doesn't set the delivery date until everything else has been settled. This probably means the real-world impact hasn't been as bad one might fear.
Context
This appears to be a regression in 4.7.31. Related PRs:
- https://issues.civicrm.org/jira/browse/CRM-21260
- https://issues.civicrm.org/jira/browse/CRM-21316
- https://issues.civicrm.org/jira/browse/CRM-21749
- https://github.com/civicrm/civicrm-core/pull/11142/
- https://github.com/civicrm/civicrm-core/pull/11653/
Solution
- Because the fix is in javascript, resolving this bug requires flushing CiviCRM caches (
cv flush
command) after upgrading to CiviCRM 5.0.0