Technical notes: this could use the opt-in queue that we established for the re-provisioning emails. That queue's consumer assumes that we're just flipping a bit on an existing donor, so we would want to extend it to use the basic donor info from payments-wiki to create a donor record if it doesn't find one for the email address. Then I think we'd need to update the Silverpop export if we wanted to include contacts with no donations.
Fri, Feb 15
Looks like the Italian hasn't been changed since last June. Italian's also still using the 20171019 email. The 2018-10-01 TY email only exists in English, Catalan, Danish, and Japanese. @jrobell what's the process for getting more translations of the new version?
Thu, Feb 14
First and Last Name search works for me too.
These tags are now showing up on meta: https://meta.wikimedia.org/wiki/Special:RecentChanges?tagfilter=centralnotice&limit=50&days=7&urlversion=2
Wed, Feb 13
diagonal banner list on Special:CentralNoticeBanners in Firefox:
Oh boy, that's some unfortunate non-handling of errors right there. We've got a try/catch around it but I guess it's non-catchable.
Testing checklist here:
Tue, Feb 12
It wan't translatable before (just a quick hack to get something for IE and GB) but it will be once we get that patch merged ^^^
Mon, Feb 11
For PayPal, it looks like we need to explicitly have the donor agree to recurring payments on PayPal's site. So we would have to bounce them back to PayPal for another authorization once they clicked 'yes'.
So we'll have to go through this one processor by processor to see which support a one-time payment with the option to set up recurring afterward without having to re-enter card details.
Looks like we're actually OK - the vast majority of today's txns at the console are from old-api recurring.
If I add up all the ones from today like 'ingenico%', 'recurring ingenico%', 'globalcollect%', and 'recurring globalcollect%', it's within two percent of the number of txns exported from today with status >=800.
Sat, Feb 9
See email Re: Changes in Platform for Wikimedia Ref : ref:_00D57ri6p._5001i1yk5m:ref
Fri, Feb 8
@Jgreen does GeoLite2 have separate databases for ipv4 and ipv6?
@krobinson sorry! I deployed something last night without testing it well. I've just pushed out a different version that should show actually the cancel button rather than breaking the whole tab
@MBeat33 we got a quick n dirty solution out there, but we haven't tested it on a real live subscription yet. Please let us know if it's working!
@Eileenmcnaughton That hack should get the button back, but I haven't tested whether the button works. A more correct alternative fix is detailed in the commit message.
Thu, Feb 7
@DStrine this should probably be done soonish. For users that come to paymentswiki without a country in the URL, we've been geocoding them with a local database of IP ranges that was updated weekly. Looks like the old version isn't going to get any more updates, so we run the risk of mis-locating people as IP addresses are bought and sold. I think the old DB never included IPv6, so we also are mis-locating more people as the IPv6 transition continues.
Wed, Feb 6
Tue, Feb 5
Mon, Feb 4
Ooh, nice! I think @Jdrewniak said that the portal was duplicating the same code to do some eventlogging outside of mediawiki. Wonder if the new stuff can help them?
Thu, Jan 24
OK, I'm seeing the loading errors in Chrome now. It's more images inlined into CSS by ResourceLoader as data: urls. This time, it's from core MediaWiki.
Did you intend to have a different field than uri_host in the OR clause looking for Special:BannerLoader? Lools like uri_host has to be exactly meta.wikimedia.org.
Looks like the php-memcache upgrades shouldn't matter. Our filters are using memcache via Mediawiki's BagOStuff interface, which has its own PHP class to talk directly to the daemon without using either of the PHP libs.
Wed, Jan 23
Tue, Jan 22
Looking at https://meta.wikimedia.org/wiki/Special:RecentChanges?namespace=8&limit=500&days=7&urlversion=2 I still see plenty of protection for formerly-unprotected translated messages, but I don't see any duplicates like we had before.
@Jgreen and @cwdent - the current thought is to keep the schema almost the same, just changing the contribution_tracking.id column from autoincrement to a writable int, and using a monotonically increasing sequence generator (probably supplied by Redis) to generate the IDs, starting with the max + 1 of the current autoincrement. Contribution tracking rows from the front end would be sent via a new queue.
Jan 16 2019
This is now deployed to all wikis. Now let's keep an eye on the protection log to see if it stops getting multiple entries
Jan 15 2019
Jan 14 2019
Awesome, thanks @AndyRussG
Jan 11 2019
Oops @Eileenmcnaughton , they DO have the same root cause! So, for this issue, we were charging people's recurring donations in USD but recording the contribution as though we had charged them in the original currency. I'll see what I can do to fix the contribution records (so they reflect the reality that we charged people in USD for a month or two).
Verified with payment 4000928094 - initiated in DKK, but the December payment was in USD. The January payment was (correctly) in DKK again.
Jan 10 2019
@Eileenmcnaughton No, I think these are actually separate issues.
@mepps one patch to add logging is deployed, but we could add logging in a couple other places to catch other sorts of failures.
This is done for this year. Since they're only valid for a year, we might think about generating a new on in June or something, so we don't have to think about renewal anywhere near Big English.
On the Ingenico configuration site (https://account.ingenico.com/) we need to click 'API keys' on the left menu, then 'Request API key', then deploy the new keys (in localsettings/SmashPig/ingenico/main.yaml). We can immediately revoke the old one or just let it expire.
Jan 9 2019
Jan 8 2019
Oh darn, it looks like we're using the converted (USD) amount for recurring payments in the new Ingenico API. I'll switch that over ASAP to use the original currency.
- needs support across more processors
- we shouldn't drop PayPal annual subscriptions that the donors have found ways to create
- new SmashPig recurring processor needs more safeguards against double charges