Mon, Nov 11
It looks like this stops working when updating PHP 7.2 to the latest php7.2 (Version: 7.2.24-1+0~20191026.31+debian9~1.gbpbbacde+wmf1) package from apt.wikimedia.org/wikimedia
Thu, Nov 7
Looks like all the patches linked to this ticket are merged so I will move this into pending deployment
Wed, Nov 6
What is the data in question that we are processing, the tracking cookies?
Tue, Nov 5
Tested out @Ejegg's patch and it now redirects to the thank you page fixing the issue.
@Ejegg could you add some notes on how I can test your patch please? Thanks in advance!
Thu, Oct 31
This is now live.
Wed, Oct 30
I think I might know what's happening here, it looks like at some point the last donor was sent here - https://payments.wikimedia.org/index.php/Special:IngenicoGatewayResult?order_id=70794726.1&hostedCheckoutId=8467accc-a8ab-47f6-821f-cb6b3bbee02f&RETURNMAC=88667854-1e67-4ffb-9890-eab8811aa34a&isFramed=false which shows a login link at the top right.
Tue, Oct 29
For vagrant users please browse to http://crm.local.wmftest.net:8080/admin/config/wmf_eoy_receipt and set the Year To Process to 2019 which should pick up any tests recurring donations recently made.
Fri, Oct 25
Thu, Oct 24
Currently we drop third-party*** cookies on a users browser after they donate to prevent repeat fundraising banners being shown across all wikimedia projects. We need to update the code that creates these cookies by adding in two additional cookie attributes, 'SameSite=None' and 'Secure=true'. To make this slightly more complicated versions of PHP prior to PHP 7.3 (released Dec2018) do not natively support the SameSite attribute. According to https://en.wikipedia.org/wiki/Special:Version we are running 7.2.22 which requires a workaround (or hack) depending on how we implement, both approaches are outlined here and here
Tue, Oct 22
- Add a couple of donations to your redis donatons queue
- Run drush qc --batch=1 -vv from your crm/drupal path
- Confirm you still have donations in your redis queue
- run drush qc -vv
- Confirm the remaining donations were processed as expected
Mon, Oct 21
Thu, Oct 17
Oct 11 2019
Oct 10 2019
Oops, it looks the like patch this ticket relates to was merged already, before I added the ticket, sorry!
Oct 9 2019
Oct 7 2019
Oct 4 2019
Oct 3 2019
Oct 2 2019
Oct 1 2019
Sep 24 2019
When the user arrives at the payments form, would we want to show either:
Sep 23 2019
Sep 20 2019
Sep 19 2019
So it looks like the gateway saved for this transaction is 'paypal_ec' and not 'paypal' as supplied in the message to the refund consumer.
Sep 18 2019
Sep 12 2019
Aug 28 2019
Aug 23 2019
Aug 22 2019
Aug 9 2019
I noticed that although there are settings for disabling PaymentsInit/Antifraud/Unsubscribe/OptIn consumers in the drupal space, the code at current isn't doing anything with this flag.
Aug 8 2019
Aug 5 2019
This looks +2able from my side. I'll just let Elliott confirm he's good with the donatewiki tables note!
All patches in the chain are now merged ready for deployment!
Jul 26 2019
Jul 24 2019
Jul 18 2019
Jul 17 2019
Jul 16 2019
Could you add some tips on how to test functionality of some of the core utilities affected please?
I think we're happy this is done as it's a prereq for FRUEC?