Ensure contributionRecurID is set on processor

[eileenmcnaughton]

Overview

Ensure contributionRecurID is available to payment processors that need it in cancelSubscription

Discussion starts here https://chat.civicrm.org/civicrm/pl/9m1goccmtpdy58cb7jyx791t7e

Before

Payment processor cannot access contributionRecurID

After

Payment processor can call $this->getContributionRecurID()

Technical Details

Payment processors can use this call
https://github.com/civicrm/civicrm-core/compare/master...eileenmcnaughton:ppal_get?expand=1#diff-96a0ea19e8ac102ef100c35b3b3d1c31R505

and then the getters will work regardless of whether the param was passed in or set

Comments

Am giving this MOP as discussed & agreed on chat with @artfulrobot

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[artfulrobot]

I think this is a good idea as we have decided to eventually get rid of cancelParams.

[eileenmcnaughton]

@artfulrobot it's probably useful to add the line

$this->inputParams = $params;

liberally in you goCardless as then you can use the getters regardless of how they were set

[artfulrobot]

Assuming this makes it into 5.20, I'm using this in my GoCardless Payment Processor:

  /**                                                                                                                                                                                       
     * Does this processor support cancelling recurring contributions through code.                                                                                                           
     *                                                                                                                                                                                        
     * GoCardless does, but only if CiviCRM version 5.20+                                                                                                                                     
     * because it depends on                                                                                                                                                                  
     * https://github.com/civicrm/civicrm-core/pull/15673                                                                                                                                     
     *                                                                                                                                                                                        
     * @return bool                                                                                                                                                                           
     */                                                                                                                                                                                       
    protected function supportsCancelRecurring() {                                                                                                                                            
      list($a, $b) = explode('.', CRM_Utils_System::version());                                                                                                                               
      return  ($a >= 5 && $b >= 20);                                                                                                                                                       
    }

[mattwire]

@artfulrobot You should be able to use PHP version_compare - various examples in core

[artfulrobot]

Ha! I had not realised version_compare was a php native function! I knew I'd seen something like that and was grepping away for 'function.*version'!

[eileenmcnaughton]

@artfulrobot the alternative is to increment the goCardless version - ie. you have a working goCardless version that people can use.

Now you are adding a new feature - if people want it they can upgrade & use it - so you add a new release in info.xml & set the version to 5.20 and people on less than 5.20 can only use the old version without the new feature. People with it can get the new version.

I switched to this approach after nearly running extended reports into the ground trying to support multiple versions. I came pretty close to abandoning it but up doing a big overhaul and changing my support strategy. Now every time I work on it I increment the supports version to what I'm working on. If people want the latest then it's up to them to figure out how to make that work.Perhaps they can run the latest version on an olde Civi - but that's nothing to do with me. The version I released for their Civi version will work as well as it always has on their version

[artfulrobot]

@eileenmcnaughton sure, I'm +1 for requiring a fairly up to date CiviCRM version. But TBH this line is for me and my clients - I'm doing the work now while they're on 5.18 or so, but want it to magically turn on when they get to 5.20. I'll need the (other) new features to work for them before they get to 5.20

[mattwire]

It's also much easier for a client to say "ok, we'll wait six months to do that report", than to say "ok, we'll wait six months to take another payment" (because the payment processor updated their API and you need to have the latest extension in civi to support it).