Oops @DStrine I didn't see your message till I had already solicited a quick review on the patch (written a couple sprints ago). I've just deployed this along with the Davivienda removal patch.

It's listing the files fine now, but when it tries to download anything over a few KB it spins for 10 minutes and dies with an IdleTimeoutException. @Dwisehaupt was able to use command-line SFTP to download a file that had failed via the python-based tool, so we can try switching to Casey's download_nightly_redux script. Just working out how to do the auth.

@AndyRussG the is_opt_out field is the older one and defaulted to 0. is_opt_in is newer and defaults to NULL, indicating that the donor never saw an opt-in checkbox.

@AndyRussG there's already code in Civi to translate from es-419 to es-mx on creation of a new donor record. Might be best to do that mapping in the preferences queue consumer too (on the Civi side) rather than letting that weirdness seep upstream to Mediawiki.

@jrobell / @LeanneS / @NNichols / @MBeat33 / @CaitVirtue / @spatton / @Ppena / @MSuijkerbuijk_WMF: Which languages should appear in the dropdown?

For the DLocal forms, should we allow ALL the payment methods that are supported in each country, filtered as usual by card/bank transfer/cash? Or just a subset?

We just deployed a fix and are no longer seeing the errors in the logs.

The LandingCheck extension should be able to do the intelligent fallback for content from one language version to another if we want to change those urls.

@jgleeson the logs show your session as having language en-gb all through the process. How did you start the donation? No chance you set the language manually in the URL?

The error in the browser console on dlocal's site is 'Promise' is undefined. This is a pretty basic concept in modern javascript, though IE never got around to supporting it. I doubt they'll rewrite their code to not use it.

OK, the second patch will change the recurring statements to 'Wikimedia 877 600 9454'

The attached patch will update the descriptor for English-language donors, for one-time and first-of-a-recurring subscription donations.

We currently use the same descriptor for credit cards and for PayPal, where it's shown on the payment confirmation screen. Any concerns with changing this for both?

note: the es-419 thank you email is renamed to thank_you.es-mx.html in https://gerrit.wikimedia.org/r/666476

That patch ^^^ should get us language fallback from es-419 to es.

This is for credit cards? Our Ingenico flow shouldn't determine whether or not to capture based on country. Any example merchant reference numbers?

To get 'es-419' in the preferred_language field we'd either have to convince upstream to lengthen the field or maintain a local hack. @Eileenmcnaughton and I feel like we could accomplish the same thing by mapping es-419 to es_MX for Civi purposes.

@EMartin For the Ingenico countries, please try with 'es' for uselang/language parameters instead of 'sp'.

The overhead of maintaining a separate mediawiki core LTS branch forever seems not worth the slight attack surface reduction of not deploying DonationInterface on the prefs wiki. MediaWiki itself is a pretty huge attack surface compared to the few DonationInterface subpages, which are disabled by default till you set globals enabling different payment processors.

It's great to see that the code has been updated at github!

Cstone I think it'll be easiest to just cancel the authorizations for all of the ones stuck in 600 status, set them back to 5 In Progress in Civi, and let today's job pick them up and start over with a fresh auth. Are you able to cancel that auth through the Ingenico console?

@MBeat33 is it preventing the search results from showing up, or just showing a distracting warning message alongside the results?

Looks like @LeanneS has created one that should work (group ID 320) - is there any more work to do on this ticket?

Ah yeah, in our first version of the SmashPig code the Approve response inherited from the Create response. We changed it so both now inherit from the PaymentProcessorResponse, and that class does have all the necessary methods called by this error handling method.

Hi @apaskulin, thanks for the nudge! I've just added it to the https://wikitech.wikimedia.org/wiki/Deployments page to go out in the next evening backports window.

@jkim_wikimedia and @RLewis, want to see if you can find data on staging to test with? You would do the search under Search->activities, from the results choose the task 'update activity status' and choose the new status, then leave the browser window open till the progress bar finishes.

I enabled the extension suggested by @Eileenmcnaughton on staging, however I'm not sure it's going to do what's necessary.

In T270472#6702548, @thcipriani wrote:

Filed upstream as: https://bugs.chromium.org/p/gerrit/issues/detail?id=13845

There is a (possibly related) issue of zuul refusing to test this merge commit: T270524: Zuul not running tests for gerrit change 650524

<Charlie Brown aaaaauuuuugh... > now reloading that workaround patch in gerrit is giving me the 500 error again. I swear it loaded the changed file list happily the first time I looked at it.

@thcipriani in your test case does the foo branch still have a 'sub' section in its .gitmodules?

Thanks for the sleuthing @thcipriani !

Seems to be complaining about the same missing blob: https://logstash.wikimedia.org/app/kibana#/dashboard/AW1f-0k0ZKA7RpirlnKV?_g=()

Oops, I spoke too soon. The first time I looked at PS2 in the gerrit UI it loaded correctly and showed the list of changed files, though zuul didn't seem to pick it up for testing. After giving the patch a C+2 (and commenting 'recheck'), the gerrit UI is back to showing

Error 500 (Server Error): Internal server error

Endpoint: /changes/*~*/revisions/*/files

Redoing the merge locally and then squashing in the vendor / composer.lock update seems to have made gerrit happy with the change. I don't see any difference between PS1 and PS2 besides the vendor pointer and composer.lock.

@AndyRussG That simplification for first release sounds totally acceptable!

OK, looks like we set that from the 'wgNoticeProject' global. Will try to figure out why that's being set to 'wikipedia' for the API portal and if we can change it.

Looks like the immediate cause of targeting banners there is that the mw.centralNotice.data.project property is coming up as 'wikipedia'.

I still can't work out exactly how this happened, but after re-queuing the messages they were all imported successfully. Closing for now.

Is it possible to pause replication to one subscriber, do the charset change on that one, then let the subscriber catch up to the current moment and swap it to be the primary?

In T264801#6675430, @DannyS712 wrote:

I've filed T269650: InvalidArgumentException on Special:EntityData for existing senses, T269651: InvalidArgumentException on zhwiki MediaWiki:Conversiontable/zh-hk - "The supplied ParserOptions are not safe to cache. Use NO_CACHE.", and T269652: RuntimeException in ApiCentralNoticeQueryCampaign - should any be a train blocker for this week, and/or prompt a revert of wmf.20 which was only rolled out yesterday/today (depending on your timezone)?

OK, the list of 421 CIDs of people who got the email but whose donation has not been cancelled is in P13545.

@MBeat33 and @krobinson there's a file with affected donor up on the filesrv under fundraising/Tech/T269372.csv

Some queries to find affected donors are in P13540

This is deployed and seems to work! With utm_medium=endowment you see the new links, with utm_medium=anythingElse you see the usual ones.

This was deployed before the recurring batch for Dec 11 GMT started, so we shouldn't see any more of these. As confirmed on IRC, the patch makes sure we only send an email on the final failed attempt, when we cancel the recurring donation.

To do this right will require slightly more complex currency validation that we currently have - Ingenico supports different currencies for different products (e.g. https://epayments.developer-ingenico.com/payment-product/mastercard/countries-and-currencies for Mastercard support).