Fix payment instrument bug by using correct payment instrument
authoreileen <emcnaughton@wikimedia.org>
Sun, 14 Jun 2020 02:36:46 +0000 (14:36 +1200)
committereileen <emcnaughton@wikimedia.org>
Sun, 14 Jun 2020 02:40:29 +0000 (14:40 +1200)
Per https://github.com/civicrm/civicrm-core/pull/17589 it is necessary that we do NOT pass the wrong payment_instrument_id
to the payment processor. BUT we have to provide accurate defaults for manual payments. This is a narrower fix than

- back office membership form
- back office participant form
- back office contribution form

and in all cases the Manual processor still loaded correctly. I don't feel I can say this is the last fix in this
area but it stands alone as a sensible fix to do and also one that should address the immediate issue.

Note there is some weirdness in a second function in EventFees - that function should GO IMHO - but I have not yet reached it in
UI testing to confirm if other changes need to be made.

CRM/Contribute/Form/AbstractEditPayment.php

index 6a328ca1e9e6b43b28e79aa0a8c44f2c50e03a65..fd7447efd8d2fd076a377796f9336674433016bd 100644 (file)
@@ -653,14 +653,15 @@ WHERE  contribution_id = {$id}
   /**
    * Get the default payment instrument id.
    *
+   * This priortises the submitted value, if any and falls back on the processor.
+   *
    * @return int
+   *
+   * @throws \CRM_Core_Exception
    */
   protected function getDefaultPaymentInstrumentId() {
     $paymentInstrumentID = CRM_Utils_Request::retrieve('payment_instrument_id', 'Integer');
-    if ($paymentInstrumentID) {
-      return $paymentInstrumentID;
-    }
-    return key(CRM_Core_OptionGroup::values('payment_instrument', FALSE, FALSE, FALSE, 'AND is_default = 1'));
+    return (int) ($paymentInstrumentID ?? $this->_paymentProcessor['payment_instrument_id']);
   }
 
   /**