A couple of small clarifications from the meeting. The third option is the one that's laid out in the description of this ticket, including the product implications.
The first two options are dependent on a little bit of experimentation; we've discussed trying to mock a few tens of millions of rows so that we can test the potential queries to see how they'd work. The two options seem encouraging to us, but we can't quite be sure that they will resolve the issue yet, so we should add that to the list of potential complications. That said, they do *potentially* give us more data to display.

Confirmed; on Firefox v73, even on not too large of a screen.

We don't have that in production so far, so I'm not sure, especially due to security concerns. We might need to have a gadget where each user must whitelist the toolforge URL individually for security and privacy.

PRU is now available on all test wikis:

The table has been created. Thank you for all the advice and guidance and help @Marostegui! And thanks, @Anomie, for the input and guidance on the best ways to approach the purging.

Investigation resolved. Next steps on followup tickets. Thank you for everyone's input!

Investigation is done; we will await next steps to create followup tickets.

Will do, @Marostegui ; FYI, I'm also tracking the creation of the table through this ticket: T244631: Create `watchlist_expiry` table in production after wmf.19 is available.

In T245082#5884033, @aezell wrote:

How will the relative bits work with translation and localization if this is truly configurable per wiki?

Just to clarify for engineering related thing, am I right to say that, basically, the message ("Both username and email address are required to receive a temporary password via email.") should never appear anywhere, @ifried ?

The product we're discussing (an expansion to CheckUser) deals with potentially large chunks of data from the database, which triggers a number of problems with regard to performance. Regardless of what method we use, we have to come up with a good way to deal with that. After discussing with the team and talking things with @Catrope for some advice around how CheckUser has historically extracted potentially large chunks of information to process, I think we have a slightly changed strategy, and have a plan.

Thank you for the analysis, @HMonroy, this is super helpful!

That's a good point also for the no-JS version.

In T244804#5870343, @Reedy wrote:

The purging operation should be done every X edits, where X is a configuration variable that has a default but can be set separately per wiki.

I would suggest adding a maintenance script (as a thin wrapper around whatever code you write) that can be cronjob'd/similar too like we do in other situations
https://github.com/wikimedia/mediawiki/blob/master/maintenance/purgeExpiredUserrights.php and https://github.com/wikimedia/puppet/blob/b347052863d4d2e87b37d6c2d9f44f833cfd9dc2/modules/mediawiki/manifests/maintenance/purge_expired_userrights.pp

Note: This process is already implemented for the RecentChanges table, which is being purged every few edits. see: https://gerrit.wikimedia.org/g/mediawiki/core/+/799eeb583a6747ad96888ec0fef8f76e45079129/includes/Storage/DerivedPageDataUpdater.php#1493

These look great, @Prtksxna !

In T240094#5847622, @Marostegui wrote:

Not sure I get this, if we move to a model where we'd be purging based on the number of edits, we should be good now?
Say we purge every 1000 edits, if that operation fails, we'd be purging once it reaches 2000?
I think one retry at least is always good, servers can be overloaded, they could be connection issues, contention issues etc...so at least a retry should be attempted I believe.

To clarify -- the wl_id was already added to the table. When we checked into this feature, we believed this RFC to be done because the details (wl_id in the watchlist table) were done, even though the original proposers then deprioritized the work on the feature. When we consulted, we were told no RFC is needed for the actual feature.

We're working on this as part of the wishlist items. We're going with the strategy of adding a new table that references the watchlist item and has an expiration.

Thank you for the quick response, @Marostegui.

In T240094#5825657, @Marostegui wrote:

In T240094#5724068, @aezell wrote:

Our hope was that having this data in a separate table would allow us to tune the automated deletions that will happen as part of expiration. If we do this in the existing watchlist table, we risk causing table locks that could significantly affect app performance.

How are you going to determine the size of the DELETE batches. Deleting is an expensive operation in MySQL, so ideally we'd prefer often but smaller transaction rather than less but bigger ones.
I also assume normal "wait for replication protections" will be used on the scripts.

Thank you for the kind words, I'm really glad you like this, and very happy to see the positive reactions overall.

The patch as written by @dbarratt looks good to me, but I'd like to make sure this complies with your recommendations, @sbassett, especially in regards to the given packages and the versioning. Since this is going to be what we base the rest of the product on, can you be so kind to do a quick pass, @sbassett https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/554229

Now that we have things organized and settled, I'm tagging DBA for assistance. Please let us know if there's anything we need to further expand on, explain, or help with. Your help is super appreciated, thank you!

After some thinking, I unfortunately think that the extension route might actually not be feasible because of the external API request (I don't think we allow for any of that in extensions in production) but either way, a question -- @MusikAnimal

This is a weird bug, but I don't think it's a problem of the character, I think there might be an issue in WhoColor with this specific article?

There is another option we should add to the investigation, @MusikAnimal -- let's also check into making WWT into a MediaWiki extension.

In T233091#5820323, @ifried wrote:

Okay, thanks, Dom. I'll keep it in the 'to be estimated/discussed' column for now, and we'll check in again at a later time to see if the behavior resurfaces.
Also, @Mooeypoo, do you think this issue was fixed in the process of the refactor work in T241004? Thanks!

Added as part of https://github.com/wikimedia/WhoWroteThat/pull/138

OK I fixed the comments, and also fixed up the request from T242954: WWT Popup: Padding changes [x-small] so this is ready for re-review.

Perfect. This can be fixed / added to the ongoing PR https://github.com/wikimedia/WhoWroteThat/pull/138

Fixed with https://github.com/wikimedia/WhoWroteThat/pull/145

Yes we can, and there's a PR for the popup css pending, but I didn't have a reference for the previous padding. I can do it by eye, or do you want to provide a number? I am guessing 0.5em and 1em but my eye is much less design oriented than yours :)

Fix is in PR https://github.com/wikimedia/WhoWroteThat/pull/138

Note: I'm fairly sure this will be a lot easier to do (if not outright fixed?) with the refactoring PR at https://github.com/wikimedia/WhoWroteThat/pull/128

That's great!! Let us know if you need any help on those (though it looks like you're super on top of everything :)

Tagging Security-Team for advice here. I think @sbassett helped us before (you might be a bit more in the loop on this?) but wasn't sure who is best to tag from your team, so I am tagging the team in general.

This is a great catch, @dom_walden !!

I've reviewed the pending patch at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/530649

I've reviewed WWT in Hebrew, and it looks great!

In T234713#5773705, @Prtksxna wrote:

I didn't know how to force an API error so I switched off the Wifi to get a generic error, is that the same?
At the moment I am not able to re-produce this either. Closing for now.

Tagging @Prtksxna and @ifried since the choice should be product/UX one. Language/translation-wise, both options are valid, but I'm not sure which one looks and feels better to users.

In T241256#5773715, @Prtksxna wrote:

We should make this white since that is part of our design elements and isn't re-using any Monobook elements.

In T239840#5750310, @Samwilson wrote:

We do have translations for zh-hant, but Firefox wants zh-tn and zh-tw; are either of these equivalent? (Translatewiki provides zh-hant, zh-hans, and zh-hk.)

@Prtksxna code-wise, this should already be happening; we're only disabling links in the html we're getting from WhoColor -- and if there's an API error we aren't getting that and are not replacing anything.

We still have the "problem" of the lighter line crossing the infobox, but now it only happens when you hover over the specific template, which (at least in my opinion) gives the user some sense of what it's attached to as a box on the screen.

The more robust architecture refactoring to do things a bit more clearer is covered in T241004: WWT: Refactor the relationship between the RevisionPopupWidget, Model and Controller for clarity

The upstream fix was merged (and deployed) into MediaWiki core, so this should be fixed without our quickfix. Moving to QA to verify.

Nice catch

Fixed here: https://github.com/wikimedia/WhoWroteThat/pull/122

After a brief chat in RL, I suggested this to @ifried :

Just a quick comment here: css filters also have their own css stack context, so they won't help :(

I did some digging into this, since it looked weird that the template starts out being behind the infobox but then ends up *in front of it* when in WWT mode. (Thanks @Catrope for the debug help here)

This is a problem with rendering templates on top of templates on wikis, and there's very little we can do as a generalized solution, since the bugs are not generalized themselves. Case in point -- if you edit this example article in VisualEditor, you'll see the same problem; hovering over the bottom template shows the "overlay" as over the image itself.

In T239680#5717468, @AronManning wrote:

My concern is whether one check (pressing the "Submit" button, switching to "Compare" tab) for multiple users should create one or multiple cu_log entries.

In T239680#5717435, @AronManning wrote:

CU log entries and CU investigations have a 1-1 relation. Calling it a "log" is arbitrary, reflecting the original use-case. Maybe calling it "CU investigations" in the DB would be more appropriate while calling it "CU log" on the UI.
I see only one limiting factor with the current cu_log table: cul_user is an N-1 relation, that cannot accommodate for multiple users checked in one investigation. That will require a new table (schema change).

During TechConf, I've discussed the implication of a periodic purge of the Watchlist table with several people, and there seems to be consensus that the general approach is sound with regards to the new table and the periodic purge of the Watchlist based on indexed timestamps of the watchlist_expiry table (ticket upcoming for the creation of that table+consultation with DBAs)

Repeating what we discussed (briefly) in an RL meeting -- We need to come up with a way to make sure the pagination works with the same state, but I am not convinced that sessions are the best way to go.

@Rxy The AHT team has taken on rewriting and redesigning CheckUser as part of the general strategy around this area. This means that we are *heavily* editing the code, and the plan is to replace the current CheckUser special page with the new one that we're building.