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?

Thanks so much for this @jgleeson! The attached patch looks great.

In T322612#8703441, @Jdlrobson wrote:

Can this ticket be closed @AndyRussG given I think you took another direction?

In T331671#8699130, @DerHexer wrote:

@Pcoombe Yes, I sadly know. And in my opinion, I consider this a bug and not a feature. Many of us are active on more than one project and get annoyed by the same banners multiple times.

In T331671#8690787, @DerHexer wrote:

Thanks @AndyRussG for fixing the preference bug!

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!!

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.

Attached patches add the required fields to the donations queue message. Test and UI elements will be included in follow-on patches.

Thanks so much @Krinkle, @kostajh !!

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.

Instructions for running under fundraising-dev with bullseye:

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.

An additional use case is the global enabling or disabling of components. Possible commands for this:
frdev disable privatebin
frdev enable donut

Fresh is now working on Donut (the MW instance with CentralNotice on the fr-dev stack).

This is working for Donut, with this patch: https://gerrit.wikimedia.org/r/885446.

Thanks for all this!!

While I'm still unable to run tests locally using npm run qunit, I've made some progress running them in the browser locally under Donut wiki on the fr-dev stack.

Two attached patches (the second one was somehow not added by gerritbot):

• Donut: Enable JS tests and remove setting
• Donut: Use /w for $wgScriptPath

From the commit message on the patch for the 2nd variant:

Hmmm maybe we're not mocking mw.requestIdleCallback in a qunit test somewhere where we should, and some recent change to CI has made calls to the original method unreliable? (More detailed explanations in also Gerrit.) Also, I do see this still happening recently, for example, here.

Another idea: an updated fr-dev CLI could also be a place to put automated scripts for the local steps needed to prepare a deploy.

Looks like the issue is the campaign seems to be set to display 0 banners per device.

Hi @Addshore! Ah interesting, thanks! They're part of the fundraising-dev environment we use to set up the diverse fundraising stack locally.

The fix for T320734 is now deployed, so the ESI comment string for testing is now being added to the base HTML for both desktop and mobile sites. So, once the cache finishes rolling over, it'll be present throughout the base HTML served via Varnish.

This is now deployed!

In T322612#8511115, @Jdlrobson wrote:

The BeforePageDisplay hook approach looks a lot better than the SiteNotice one @AndyRussG (enabling $wgMinervaEnableSiteNotice would have likely caused a lot of issues with user notices on mobile). If you need the ESI string to go inside banners in future, I'd suggest we do some refactoring of Minerva to achieve that. Glad to hear you are unblocked!

Current version of the attached patch seems to work! I think at least a bit more testing and study is needed to check for possible side effects/edge cases. Also I feel we'd we need to fix exception thrown and add inline comments to explain how things work.

Note: hoping to deploy the latest fix to production pretty soon, possibly this week. This would cause the test ESI comment string to be injected on both desktop and mobile sites (rather than just desktop, as is currently the case). Thanks!

Quick update: the patch in question was looked over by other fr-tech engineers and we agreed it seems extremely safe. So, we merged it to master, which meant it has been deployed to the beta cluster, but not to production, since December 15th.

https://docs.google.com/document/d/1hNmtrmeFACnvmQ5QhXY898Aen69X20YPiawVp7iqABk/edit?usp=sharing

Here's a proposal for the command-line interface. Let's have a single base command, say, frdev, with various subcommands to perform specific actions.

I'm able to reproduce this, or something similar to this, locally, with the following procedure:

• Open an Adyen cc form.
• Fill in the form using test card info.
• In the JavaScript console, execute:

$( '#paymentSubmitBtn' ).click(); $( '#paymentSubmitBtn' ).click(); $( '#paymentSubmitBtn' ).click();

In T143266#8441706, @greg wrote:

Verify your ability to log in to external and internal services, including access to 2FA tools required to do so.

Do we have a list of what those are so people can verify?