Fri, Feb 21
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.
Thu, Feb 20
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:
Wed, Feb 19
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.
Tue, Feb 18
Mon, Feb 17
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.
Sat, Feb 15
Fri, Feb 14
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.
Thu, Feb 13
Wed, Feb 12
Tue, Feb 11
Thank you for the analysis, @HMonroy, this is super helpful!
That's a good point also for the no-JS version.
Mon, Feb 10
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
Sat, Feb 8
These look great, @Prtksxna !
Wed, Feb 5
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.
Tue, Feb 4
Thank you for the quick response, @Marostegui.
Sun, Jan 26
Thank you for the kind words, I'm really glad you like this, and very happy to see the positive reactions overall.
Jan 23 2020
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
Jan 22 2020
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
Jan 21 2020
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.
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.
Jan 16 2020
Perfect. This can be fixed / added to the ongoing PR https://github.com/wikimedia/WhoWroteThat/pull/138
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 :)
Jan 13 2020
Fix is in PR https://github.com/wikimedia/WhoWroteThat/pull/138
Jan 9 2020
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
Jan 8 2020
Jan 7 2020
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 !!
Jan 5 2020
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!
Jan 3 2020
Jan 2 2020
@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.
Dec 17 2019
Dec 13 2019
Dec 10 2019
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.
Dec 6 2019
Dec 5 2019
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)
Dec 4 2019
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.