"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:

Solution

Because the fix is in javascript, resolving this bug requires flushing CiviCRM caches (cv flush command) after upgrading to CiviCRM 5.0.0

Edited Apr 15, 2018 by mfb

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information