Looks like maybe a couple of mistaken imports? Anyway, they do all seem delete-able from the spot checks I've done so far.

@EMartin When I limit the cancel reason to just 'auto (maximum failures reached)' for October, November, and December, I actually see only 5,877 cancelled Ingenico recurrings. This is fewer than either of the previous two 3-month periods - there were 7,586 cancels for multiple failures in July, August, and September, and 8,094 cancels for multiple failures in April, May, and June.

We should also probably exclude

• anyone who we canceled because the charge failed due to of one of the reasons that they can fine us for retrying
• anyone with a chargeback associated with a recent donation

OK, the settings form should be working again.

Hi @NNichols on that ticket it looks like after some back and forth you came around to the idea of keeping the financial type ID: https://phabricator.wikimedia.org/T343756#9120225

We never made a ticket for it, but those custom 'Smashpig' fields should be collapsed by default and read-only now as well.

OK @AMJohnson and @krobinson I just deployed a patch to add details about changes to next scheduled date and cycle day.

OK, there is a JSON IPN listener ready for some smoke testing

"We were unable to find a donation form matching your parameters. Please contact our help team for more information. "

@NNichols can you point to some discussion about removing the 'Endowment Gift' financial type? We're using that in a bunch of places to decide how to treat endowment donations.

So it looks like this is one of those errant annual paypal payments that someone managed to make. We have a job to cancel old subscriptions where there has been no charge for 90 days. Perhaps we should limit that to just 'monthly' subscriptions?

Confirmed that the error text is about a third of the way down the big blob of JS loaded from https://checkoutshopper-live.adyen.com/checkoutshopper/sdk/5.39.0/adyen.js

(copied from T223330)
@AKanji-WMF, @XenoRyet , @DBu-WMF Can you help us determine the current requirements for an unsubscribe page? The patch in review uses a link with a contact ID and a checksum like those for the email prefs pages, then has the donor fill in their email and click to confirm the unsubscribe.

So, we will gain the ability to set this limit this as a result of the work that Eileen's doing on generic Queue Consumer actions. BUT.... I propose we don't add one. This has always happened as a result of our getting hit by a spammer, and it's better that we get failmail when that happens. It's of course better to detect even earlier but this is at least one way to learn about it.

This is part of the security scanning - it's a check for whether we offer directory listing where we shouldn't

The recurring failure email is in production. We do NOT send it when the donor already has another active recurring.

This is done

Looks like @JMando is doing something similar in T356911: New Donors Donating On Email

moving to holding pen based on Eileen's last comment

We're still checking for financial_type=Endowment Gift to decide

@AMJohnson and @krobinson all of the recurring contributions should have financial type cash now!

@Anil this might be an easy win for volunteers. It would just need an extra UI element in the CN admin screen to select groups of countries, no need to change any other code.

OK @krobinson and @MBeat33 we have updated the logic to attempt sending the recurring failure email including to contacts whose email is on hold.

Looks like this is all set. smart_group_cache_refresh_mode is currently set to 'opportunistic', and the delete_deleted_contacts job is running without deadlocking everywhere

Awesome @ehughes, that's what we were hoping to hear!

Seems to relate to the old integration, which we're about to remove.

Moving to holding pen

Optimistically moving this to Done with the upgrade to Smarty 3

@krobinson I don't think it's all Civi sends - we do send the EOY emails to 'on hold' addresses for example. This email does a specific check for 'on hold', but we can easily remove that.

Looks like we'd have to override it in the image:

Hmm, the new queries might not be set up right:

In T317837#9519241, @Ejegg wrote:

Looks like we can just add a getInstanceFromJSON method to the AdyenMessage class that parallels the current getInstanceFromWSDL method.

Then we also add a constructFromJSON to replace constructFromWSDL, on AdyenMessage and any subclasses that override the WSDL one.

Optimistically moving this to done, can reopen if Smarty3 hasn't fixed it for us.

Looks like we can just add a getInstanceFromJSON method to the AdyenMessage class that parallels the current getInstanceFromWSDL method.