CRM-20800 fix fatal error up updating paypal contributions #10986
Conversation
|
Jenkins test this please |
|
Jenkins test this please |
| $this->_paymentProcessor = CRM_Contribute_BAO_ContributionRecur::getPaymentProcessor($this->contributionRecurID); | ||
| if (!$this->_paymentProcessor) { | ||
| try { | ||
| $this->_paymentProcessor = CRM_Financial_BAO_PaymentProcessor::getPaymentProcessorForRecurringContribution($this->contributionRecurID); |
There was a problem hiding this comment.
actually it needs to be $this->_paymentProcessorObj = CRM_Financial_BAO_PaymentProcessor::getPaymentProcessorForRecurringContribution($this->contributionRecurID);
I think, but the issue is a bit more than this. I think it's about making it so a cancellation happens if UI changes (changing installment number, end_date) effectively cancel it. I think it might be easier to change installments on the form when end_date changes - or force user to & possibly move this to the ContributionRecur BAO
There was a problem hiding this comment.
Agree of what need to be addressed, I made the revert to fix a issue mentioned by reporter - https://issues.civicrm.org/jira/browse/CRM-20800?focusedCommentId=108162&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-108162
I though the same but then $this->_paymentProcessor will be set to NULL which later assigned at L140. Although I found no use of $this->_paymentProcessor anywhere in UpdateSubscription php or template, so we might need to keep any one form variable, that would be:
- Rename
$_paymentProcessorObjectto$_paymentProcessor - Remove
$_paymentProcessorObject
| $this->_paymentProcessor = CRM_Contribute_BAO_ContributionRecur::getPaymentProcessor($this->contributionRecurID); | ||
| if (!$this->_paymentProcessor) { | ||
| try { | ||
| $this->_paymentProcessor = CRM_Financial_BAO_PaymentProcessor::getPaymentProcessorForRecurringContribution($this->contributionRecurID); |
There was a problem hiding this comment.
Had a hard time in replicating the issue, so I am relying on reporter's response :(
|
@monishdeb I'm going to merge this - it is simply improving the way in which the payment processor is loaded. We collaborated on it before and I have come back to it after so long I feel able to be an 'independent reviewer'. My main concern is that not getting this merged has stalled the JIRA on a critical issue. I think this may not be the fix but I think it will be hard to move forwards without merging it |
|
Agree 👍 |
|
Now we have to try to get the reporter to confirm his current experience.... |
| @@ -87,6 +87,7 @@ public function preProcess() { | |||
| catch (CRM_Core_Exception $e) { | |||
| CRM_Core_Error::statusBounce(ts('There is no valid processor for this subscription so it cannot be edited.')); | |||
| } | |||
| $this->_paymentProcessorObj = $this->_paymentProcessor['object']; | |||
There was a problem hiding this comment.
@monishdeb @eileenmcnaughton I've just run into this line on master and it seems to be breaking the "update subscription" functionality for me. I'm using the smartdebit extension and I get a php crash because $this->_paymentProcessorObj is not an object. Running through a debugger the "object" is actually $this->_paymentProcessor and there is no 'object' array element. Do either of you understand what this line is supposed to do - is it something that needs updating in my smartdebit extension?
There was a problem hiding this comment.
arg -does this work?
The assigns to the tpl seem no longer required - we call the payment processor to determine what fields can be edited & what text should be rendered
$this->editableScheduleFields = $this->_paymentProcessorObj->getEditableRecurringScheduleFields();
$changeHelpText = $this->_paymentProcessorObj->getRecurringScheduleUpdateHelpText();
There was a problem hiding this comment.
Yes it does! Well I tested UpdateSubscription at least and that seems to work fine with that additional patch
CRM-20800 fix fatal error up updating paypal contributions
Overview
Fix for Paypal cancel link giving fatal errors in some circumstances,
Technical Details
I have not been able to replicate this but am hoping the reporter can fix this. The code is an improvement as it is loading the payment processor directly based on the recurring contribution id rather than using an indirect method that we should view as legacy