Oh hey, that was easy! *poof* and it's gone

OK, I'll see if I can figure out how to decommission it to free up those resources.

Looks like it's actually reasonably current - it was last updated in September.

Oh yeah, those are built from a hard-coded list that we update 1x a year or so. It's probably overdue for another update!

Yep, I just checked (by highlighting the white-on-white text) and it does indeed just say Total 30.00 SEK (since we don't send an itemization).

It looks like we can change this text via the language packs in the key gc.general.paymentProductFields.validationErrors.allowedInContext.label

@DStrine I got some bad news from our Adyen contact on Friday - they decided not to build the HPP integration for Apple Pay. So to get it through Adyen we'd need to switch to the Checkout integration.

The title of the page is 'Cards', which we should probably change too. It seems to be set in the language pack's gc.general.paymentProductGroups.cards.name

We're limited in our ability to change this page. They let us hide certain elements, but to hide the 'shopping cart' (list of items and prices) we had to set the text to white on white. Here's an example of what it would look like to change it back to black text on white:

Payments-wiki requires javascript too - there's really no way to get to the credit card entry without it. That error is probably just triggered because the random card number doesn't pass the Luhn check. If you want a test card number that doesn't trigger the check error, you can always use 4111 1111 1111 1111.

@CDenes_WMF these are all on the staging server. Feel free to use the TY mail test page to send them to yourself and anyone who's helping review them.

Did the versions sent on Jan 7th look good? I don't see any obvious errors looking at the patch.

Is cn-staging-1 used for anything? I see it's on stretch while -2 is on buster.

Hmm, and while Portuguese regions DO have numeric identifiers, US regions should be using the 2 letter state abbreviations.

I would expect to see the countries in alphabetical order whether they had regions or not, and have the regions listed in parenthesis after their relevant country. So something like

BR, CA (AB, BC), CO, US (MA)

To represent all of Brazil and Columbia, the US state of MA, and the Canada provinces of AB and BC.

On second thought, no, let's send all payment messages to the donations queue.

The recurring-specific normalization has two parts: 1) finding the contribution_tracking_id and 2) dealing with paypal inconsistencies in migrating legacy to new subscription ID formats.

Here's what we got from Adyen back in 2016:

These docs have been moved and updated

• https://www.mediawiki.org/wiki/Fundraising_tech/Queue_message_formats
• https://www.mediawiki.org/wiki/Fundraising_tech/Message_queues

I had basically fixed it locally to confirm that it was my PS25 change at fault, so I went ahead and pushed that up. The multiselects and the geotargeting bits should now work in the 'add campaign' section like they do on the 'edit campaign' page.

OK, it's due to a change I made to centralnotice.js back in PS25 - I took a chunk of UI initialization code and moved it from centralnotice.js into campaignManager.js:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/518449/24..25

Yep, something's busted there. Looks like some scripts aren't being loaded. The multiselects for language and project are also unstyled.

Once we get some things set up (users, content), we should back up the db and make it easy to restore if the vagrant box gets wiped and reinstalled.

I think we want to pull all of them onto the staging server to test

Nice! Looks like https works too: https://cn-stage-2.wmflabs.org.

Ah, just saw your update. So we should probably change the title of the column (maybe Geotargeting?). The list would look something like CO, US (MA) to indicate that all of Colombia and the US state of MA are selected.

This ticket is about fixing it in the campaign list (the main page that shows up on Special:CentralNotice).

Looks like the phan checks were fixed by someone upgrading the mediawiki-phan configuration (one of the dependency updates). The link above was to some Jenkins logs, which I guess get purged pretty often. It was showing one of the Phan checks saying we were vulnerable to XSS, but now I don't think it was accurate. So... I think we can close this ticket!

When I pull down the latest version of the patch I still see separate columns for country and region: F31550196. Do you have local work to combine them?

The task list from @XenoRyet looks pretty good!

Weird - the original donor should have gotten through based on the current rules, which just look for a 10 character string.

Here's a draft of a SQL query to make a refund CSV for the Ingenico donations: P10291

There are timeouts in the logs for both the PayPal and the Ingenico donations mentioned here. Looking at email addresses with multiple donations in a day, there were 25 on Jan 26th, 47 on Jan 27th, and 4 each on the 28th and 29th.

Also note that you can get to the paypal record by adding the subscr_id (starts with I-) to the end of this URL:

As of Jan 24 2020 the status of the contribution and contribution_recur records were both complete, but I will manually set those two to canceled so as to make our totals more accurate.

It looks like our helpful translate-wiki friends have already translated the payments-wiki text into French, Turkish, Brazilian Portuguese, Norwegian, Hebrew and Arabic, with partial translations in a few other languages.

@Jgreen and @Dwisehaupt : We have a Cloud VPS project! You are both admins, along with the rest of us on fr-tech. I'm reading through all the links from https://wikitech.wikimedia.org/wiki/Help:MediaWiki-Vagrant_in_Cloud_VPS before I actually take any of the steps there, so nothing is set up yet.

There's this: https://github.com/civicrm/civicrm-core/pull/15235 , in which we try to be all clever and actually guarantee a continuous sequence of numbers starting from wherever you start.

Hi @MBeat33. @AndyRussG (along with @Cstone and @Eileenmcnaughton) exported a file with the problems and ran the batch refund.

Our project has been approved and we can start setting up an instance! I've added all of fundraising tech as admins. To log into https://horizon.wikimedia.org we'll all need to turn on 2FA for our Wikitech accounts.

Thanks @Bstorm ! I've added the rest of fundraising-tech (including ops) as admins.

Well, the rebase worked fine, but we're now failing tests because of a couple new Phan checks. Fixing one of them just needs a @suppress comment, but this one should probably be fixed in code: https://integration.wikimedia.org/ci/job/mwext-php72-phan-seccheck-docker/29593/console

The big rebase that needed some code rewritten is already done, and I did another simple rebase on Jan 3rd. I'll try another rebase now just to make sure nothing else has come in that will interfere.

Also maybe related to T129379. That 'Stop denormalizing' patch may have fixed it.

So I haven't yet implemented any of the changes mentioned in David's and my comments from Dec 18th: https://phabricator.wikimedia.org/T226438#5751615

Looks like a cloud VPS project is what we want here, potentially using https://wikitech.wikimedia.org/wiki/Help:MediaWiki-Vagrant_in_Cloud_VPS

Adding the authorize call can be an opportunity to define the normalization of the API responses.
So for example instead of passing back { 'pspReference':1234567 } it would pass back { 'gateway_txn_id':1234567 }

We're pretty clear on where everything needs to go.

If they're sent in the same format as the payment tokens for Ingenico Connect, we shouldn't need any change in the queue consumer. We just need to update the Adyen gateway code in DonationInterface to add the shopperReference to the queue messages as 'recurring_payment_token'.

To investigate: is anything like this still happening for Ingenico Connect? The limbo queue is now the pending table, and we delete from that when we get a donation or payments-initial queue message with the final status of the donation attempt.

As a fix, the pending database could fall back to invoice_id when order_id is not present.

The bit about the cardholder name is somewhat confusing on that page. It says

As the cardHolderName is a required property in most regions, we will also automatically capture that property in case 3-D Secure has been enabled on your account.