From 80955669a211795d6838d9ff38ca77668672b06f Mon Sep 17 00:00:00 2001 From: Tim Otten Date: Fri, 30 Mar 2018 15:02:42 -0700 Subject: [PATCH] (dev/mail/5) "New Mailing" - Previews should not schedule real blasts In `CRM_Mailing_BAO_Mailing::create` and `Mailing.create` API, there is a (*ahem*) special behavior where setting the `scheduled_date` will immediately trigger scheduling. One shouldn't submit `scheduled_date` for a preview. This was not symptomatic before #11142/v4.7.31 because all preview operations were wrapped in a transaction and rolled back. But now previews are allowed to have side-effects, so we need some other means to prevent. This copies the workaround from `crmMailingMgr.save()` and applies it to `crmMailingMgr.preview()` (etal). --- ang/crmMailing/services.js | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ang/crmMailing/services.js b/ang/crmMailing/services.js index 4eb62381f2..cfaaeda2b1 100644 --- a/ang/crmMailing/services.js +++ b/ang/crmMailing/services.js @@ -275,6 +275,7 @@ id: '$value.id' } }); + delete params.scheduled_date; delete params.recipients; // the content was merged in params._skip_evil_bao_auto_recipients_ = 1; // skip recipient rebuild on mail preview return qApi('Mailing', 'create', params).then(function(result) { @@ -300,6 +301,7 @@ 'api.email.getvalue': {'return': 'email'} } }); + delete params.scheduled_date; delete params.recipients; // the content was merged in return qApi('Mailing', 'create', params).then(function (recipResult) { // changes rolled back, so we don't care about updating mailing @@ -332,6 +334,7 @@ }); crmMailingCache.put('mailing-' + mailing.id + '-recipient-params', params.recipients); } + delete params.scheduled_date; delete params.recipients; // the content was merged in recipientCount = qApi('Mailing', 'create', params).then(function (recipResult) { // changes rolled back, so we don't care about updating mailing -- 2.25.1