User Details
- User Since
- Oct 28 2014, 2:36 PM (489 w, 6 d)
- Roles
- Disabled
- LDAP User
- Unknown
- MediaWiki User
- AGreen (WMF) [ Global Accounts ]
May 25 2023
Apr 7 2023
Thanks @Quiddity! Certainly that's fine! Though it might also be clearer to mention that the settings to disable certain banner types are only available to logged-in users? What about something like this:
Mar 28 2023
Initial, tentative work on this: this fr-dev patch and this related dev-images merge request (which I should break into multiple merge requests, as suggested by @jgleeson, so the unrelated Civi bullseye upgrade can be considered separately).
Recent example: See failmail with the subject, "Fail Mail (civi1001) run-job: Donations queue consume failed with code 135", from 2023-03-23. Referenced log file is /var/log/process-control/donations_queue_consume/donations_queue_consume-20230323-094701.log.
Hi! The linked DonationInterface patch has been deployed, and the form does ask for UPI ID when we specify recurring=0 and payment_submethod=upi on the URL.
Mar 26 2023
A bit more discussion here (internal WMF Slack).
Mar 22 2023
Notes for current sprint: https://etherpad.wikimedia.org/p/fr-tech_chores_2023_fish_HEAD%5E
Mar 20 2023
Just to confirm, the issue with user preferences not correctly hiding banners based on type: this part of the system now seems to be working as expected. Is anyone still experiencing this specific bug?
Mar 17 2023
Thanks so much for this @jgleeson! The attached patch looks great.
Mar 16 2023
Mar 15 2023
Mar 14 2023
Heyyy here are some quick notes:
- I was able to reproduce this on production just by disabling banner categories in my preferences and seeing what happened. Not sure why you're not seeing any banners, @TheresNoTime.
- The fix turned out to be quite simple. It has been merged and placed on this week's deploy train. It should be deployed to most Wikipedias on Thursday, and to most other projects and a few Wikipedias on Wednesday.
Apologies for the delay in getting to this, and for not writing more details just now. (FR-Tech is rushing to get a new payments integration finished this week.) I'll try to find time later this week to explain more and reply to some comments above.
Thanks again!!
Mar 13 2023
Thanks so much for this, it's been immensely helpful!! As noted here T331671#8688951, it looks like there is indeed be a bug. I'll post more on the parent task as soon as I can.
Thanks so much everyone for your input and effort on this, and many apologies for the delay.
Mar 9 2023
Mar 8 2023
Mar 1 2023
Attached patches add the required fields to the donations queue message. Test and UI elements will be included in follow-on patches.
Feb 24 2023
Feb 22 2023
Feb 16 2023
Feb 14 2023
Feb 13 2023
Summary
- The updated code for this is merged and deployed, but I'm unable to turn on the process-control job myself due to a permissions issue. (Can't push to fran1001:/var/lib/git/localsettings.git/)
- Comparing the output of the old and new versions of the script, via spot-checking, we see the following:
- Data in banner impressions seems identical.
- Data in landingpageimpression_raw seems almost identical.
- Data in donatewiki_unique seems to get additional entries with the new script. These entries are not present in data generated previously by the old script in the production pgehres database. However, this was probably due to an issue with the old script, or something related to the setup at that time, causing the old script to incorrectly drop data.
Feb 7 2023
Instructions for running under fundraising-dev with bullseye:
Feb 6 2023
Thanks @Jdlrobson! I'll make a CN patch just to always expose a mw.centralNotice.isBannerShown() function no matter what, since that seems like the most logical way for the CN JS API to work, and would prevent errors like the one mentioned in the task description.