As jgleeson says, we're not getting capture IPNs here, so this wouldn't be especially useful. And I found a different problem at the root of T345097.

OK @nisrael , there was a query hanging. We had to terminate it and re-run the export, but it has gone through this time. Would you, @KHaggard , or @ppenloglou like to kick off an additional import from the Silverpop side?

Hmm, there's no failure in that log, it just seems to trail off. I'll try running it again and see if it works.

In T346819#9189156, @KHaggard wrote:

Hi @Ejegg - quick clarification, our emails targeted AF_has_active_recurring_donation = No. So the 'pending' donors have "No" as their value currently.

That field is a Yes/No only field and I don't believe there are any blanks except for edge cases.

@AKanji-WMF I think we can decline this - it's working as expected, warning banner designers about non-wikimedia scripts that may be loaded when they load the banners. If some of those are loaded via their own gadgets, that's an unfortunate false positive, but it's better that than we get somebody loading a facebook tracker on all wiki pageviews by mistake.

Application Security Review ticket submitted at https://phabricator.wikimedia.org/T347104

So fr-tech: the pending donations are being excluded by this INNER JOIN on civicrm_contributions. We could just change it to a LEFT JOIN and get the pending rows. Only drawback I see is that it might pick up some people whose recurring donations have all been refunded.

Thanks @KHaggard ! So for the monthly convert donors who haven't yet made their first recurring installment (and thus has status pending), I guess AF_has_active_recurring_donation should be 'Yes' but AF_recurring_latest_donation_date would be blank.

However, if it is easier to keep the existing automatic PayPal import, is there a way that I could pull a list of those PayPal gifts with the custom (Give Lively) field? I could potentially add the DM appeal manually after the gift is in Civi.

OK @KHurd-WMF , I'm adding the recommended tags here.

@MBeat33 just to confirm @Cstone's theory, I checked on 187546189.1 and found that we did actually collect names and send them to the queue from paymentswiki.

Looks like this was deployed just before the last Civi upgrade.

Hi @aranyap, we're still talking about the same use case - only loading the Fundraise Up scripts for people who choose to donate. So this ticket is limited to just changing the CSP headers on donatewiki, no other foundation sites.

Hi @KHaggard and @krobinson, how are you targeting the email campaign? Is it via a search or group of CIDs exported from Civi, or is it via some of the custom fields that we send to Acoustic? If it's the latter, we could try changing how we export these donors.

HI @Sbasset, I just heard from @ERoden-WMF that the initial security review was done by @Aprum / @aranyap . I see @JFishback_WMF and @KHurd-WMF CC'ed on those communications as well. I hope that helps!

Got the CRM tests moved over to 7.4 (thanks hashar!)

Our tech contact says that MP seems to be disabled in their console for our account. Probably can ignore these error messages.

The usage of CLDR in DonationInterface is fairly limited - We use LanguageNames::getName() on an email preference form, and for payments forms we're getting the name of the country in the user's language for a message in the footer that is only shown in France.

"Notre statut d’exonération varie selon la législation de chaque pays. Les dons à la Wikimedia Foundation ne sont pas déductibles des impôts en France."

@Pcoombe I've put up a mediawiki-config patch for review to add fndrsp.net and *.fundraiseup.com.

This was closed by fr-tech-ops because it's not on their server. Reopening it to associate a mediawiki-config gerrit patch and get sign-off from Security team for the addition to the CSP (I'm assuming they already approved the actual integration while I was on sabbatical). @sguebo_WMF and @Reedy please let me know if I should tag any Security people not named Sam.

Jeff and Dallas, I think you looked into this already, right?

It's working!

@AKanji-WMF Nope, this was the analytics thread about tracking the variant and the appeal: https://app.slack.com/client/T024KLHS4/GNT0JM91U/thread/GNT0JM91U-1694038818.665359

Blocking task for CiviCRM tests: T307178

Thanks @jgleeson! Explicit parameters seem even better than just detecting failure. They also let us send additionalData.manualCapture = true for credit cards.

In T334904#9158302, @AKanji-WMF wrote:

Triage Sept 11 determined we'd likely want to address this after Dec 23

Looks like all of those innodb_ variables being set in ci-create-dbs are being set to the default values as of mariadb 10.5, so I think we can just skip that file entirely!

Upstream issue: https://lab.civicrm.org/dev/core/-/issues/3586

The DI form part of this is deployed, but I think the SmashPig patch still needs a release tagged to go out with CiviCRM for recurring installments (Though I'm not sure we have any yet for ZA)

The current top one in the damaged queue (ZHBRDHJSVFHSD272) is an iDEAL donation - we recorded the capture notification in payments-listener-adyen-20230818.gz . The donation is in Civi with gateway txn ID LHS245LCTFHSD272 though, which I think was the auth PSP ID.

Are we successfully marking ANY Adyen refunds at this point? Are we potentially saving the wrong txn ID (auth vs capture)? Should we save both?

Change log for the settlement detail report:

Thinking about ways we could have detected this:
The problem was that we wrote code assuming the Adyen settings would remain at auto-capture, and recorded donations as captured as soon as we authorized them. Could we change our code so that when we are just authorizing a donation, we only send the information to the pending queue, and we wait for the capture IPN to actually record the donation to Civi as captured?

@EMartin Many of these countries are not listed as supported in Adyen's documentation, or only support payment methods that we don't offer. For example, filtering by country TW only shows Alipay as supported: https://docs.adyen.com/payment-methods/?countries=tw

I think we have historically focused on 'Save to CRM' rate because that's where we do the most database activity, so it's the limiting factor in how fast we can show results and get the TY letters out. For a while, the most frequent causes of these things slowing down were DB changes in CiviCRM that slowed our usual queries or changes in our code that made us do more DB work for each transaction. Focusing on just the 'Save to CRM' rate made those slowdowns easier to detect.

@Damilare With the new (dlocal) integration I seem to be able to get ZA card payments through on sandbox without including any placeholder

If we need to also handle direct links to Special:IngenicoGateway we can probably rewire that url to use the Adyen classes via the extension.json "SpecialPages": { } block