User Details
- User Since
- Oct 8 2014, 11:22 PM (339 w, 5 d)
- Availability
- Available
- LDAP User
- Ejegg
- MediaWiki User
- EEggleston (WMF) [ Global Accounts ]
Thu, Apr 8
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.
Tue, Apr 6
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.
Thu, Apr 1
@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.
Tue, Mar 30
Thu, Mar 25
@jrobell / @LeanneS / @NNichols / @MBeat33 / @CaitVirtue / @spatton / @Ppena / @MSuijkerbuijk_WMF: Which languages should appear in the dropdown?
Wed, Mar 24
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?
Tue, Mar 23
Wed, Mar 17
We just deployed a fix and are no longer seeing the errors in the logs.
Mar 9 2021
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?
Mar 3 2021
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.
Mar 2 2021
Feb 26 2021
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?
Feb 25 2021
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?
Feb 24 2021
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.
Feb 23 2021
Feb 18 2021
@EMartin For the Ingenico countries, please try with 'es' for uselang/language parameters instead of 'sp'.
Feb 17 2021
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.
Feb 16 2021
It's great to see that the code has been updated at github!
Feb 11 2021
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?
Feb 10 2021
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.
Feb 9 2021
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.
Dec 23 2020
@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.
Dec 21 2020
Dec 18 2020
<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.
Dec 17 2020
@AndyRussG That simplification for first release sounds totally acceptable!
Dec 16 2020
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?
Dec 14 2020
OK, the list of 421 CIDs of people who got the email but whose donation has not been cancelled is in P13545.
Dec 12 2020
@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
Dec 11 2020
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.
Dec 10 2020
Dec 9 2020
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).