Closed mattwire closed 3 years ago
Thanks, Matt. I think it does still need to be an option, though one that defaults to ON. Otherwise we need to handle cases when the API call fails but the Civi process should succeed. These are rare but they do happen especially in testing.
I like the "texts" stuff.
Ok, @artfulrobot I pushed an update that should work in all cases for 5.24+:
doCancelRecurring()
.isNotifyProcessorOnCancelRecur
on propertyBag.isNotifyProcessorOnCancelRecur
- I still need to check if this is set for frontend cancellations.Also, a (gocardless) recur in Pending
state does not have a subscription ID (processor_id) so cancel will fail. Maybe that's only a problem on my local dev because I'm not getting webhooks?
@mattwire yeah but we don't care about those 😉
A GC recur will only be Pending for 24 hours or less (maybe 1 hour) then Cron changes it to cancel or failed, can't recall. Normally it will be In Progress. If it's pending then you can't cancel it cos it doesn't exist (at GC) yet.
@artfulrobot I've updated the description - I think this should be ready for review now.
This implements support for payment propertyBag and
doCancelRecurring()
/cancelSubscription()
for subscription cancellations.Some notes:
I've implemented
And the frontend (with https://github.com/civicrm/civicrm-core/pull/17687):
![image](https://user-images.githubusercontent.com/2052161/85880123-65ac6200-b7d3-11ea-9695-1d0da1c226b6.png)
supportsCancelRecurringNotifyOptional()
and set it to TRUE. This means that the user will see an option to notify gocardless (defaults to Yes) on versions of CiviCRM that support this (5.27). In the backend they will see:This drops support for CiviCRM < 5.24 - I think you'll have trouble getting everything working on versions much older anyway..