[WIP] Fix subscription urls

[Edzelopez]

Overview

This is an initial attempt to fix the errors when cancelling and updating billing details for a recurring contribution using self serve links. #127

Before

1. Trying to cancel a recurring payment using the self serve link results in an error:
   InvalidArgumentException: "processorID field has max length of 255"

#0 /xxx/civicrm/CRM/Contribute/Form/CancelSubscription.php(217): Civi\Payment\PropertyBag->setRecurProcessorID(NULL)

This was due to the absence of the processor_id in the civicrm_contribution_recur table.

2. Trying to update billing details, gives the following error:
   Exception: "This system is unable to perform self-service updates to credit cards. Please contact the administrator of this site."

#0 /xxx/civicrm/CRM/Contribute/Form/UpdateBilling.php(207): CRM_Core_Payment_iATSService->updateSubscriptionBillingInfo(NULL, (Array:21))

This was due to the absence of the crid(recur_id) param in the URL.

After

The links now function as expected, allowing one to cancel or update the billing details for a recurring contribution.

Comments

The fix around passing the extra recur_id param may likely need to be expanded to handle the various other calls to this function from different instances. Hence, marked this as WIP, to open discussions for the same.

[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).

[mattwire]

I would prefer to see these moved to a token implementation rather than being fixed via the smarty route. We've made some good progress on tokens recently.

I'd suggest:

1. If we can get Standardise what we pass to tokenProcessor so we don't have to add specific handling in each class for actionSchedule #16983 reviewed and merged then it becomes simpler to implement a contributionRecur tokenProcessor class.
2. You can more or less copy CRM_Activity_Tokens to create CRM_Contribute_Recurtokens (or similar).
3. Trigger tokenProcessor when sending the message template so we parse contributionrecur tokens. (This also gives us a path to deprecate the older token methods later). I can help with this part.
4. Pass the recur ID through with message template params so that it's picked up by tokenProcessor.

[mattwire]

Additional benefit would be that we'd get recurring contribution tokens that we don't currently have.

[JoeMurray]

It seems like you're asking for a fair bit of work here, @mattwire . @seamuslee001 is going to take a look too and provide feedback. We've got a limited budget and even more limited timeframe for completing this. Which isn't to say it wouldn't be nice to have all the stuff you're suggesting.

[mattwire]

@JoeMurray I know the feeling :-) In that case let's fix the bug but see if we can do anything to make future cleanup easier. Just improving the comments on the params to subscriptionURL would certainly help.

[seamuslee001]

I'm not 100% sure this is correct,

The processor_id is meant to be the unique token or similar that is used when charging the payment. The payment_processor_id = the id of the PaymentProcessor that is used from civicrm_payment_processor table

[Edzelopez]

Makes sense. I figured the processor_id == payment_processor_id, which is not true.

[eileenmcnaughton]

I'm pretty sure this was otherwise fixed as a regression a while back

"#0 /xxx/civicrm/CRM/Contribute/Form/CancelSubscription.php(217): Civi\Payment\PropertyBag->setRecurProcessorID(NULL)"

• now treats NULL as acceptable