Tests in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1131366 are failing after latest changes to add permission checks in formatComment, moving this task back to 'In Progress'.

All patches have been merged, so I'm moving this to QA.

Tests in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1142587 are now passing, and the patch is being merged, Moving the task to QA.

Test are now failing after rebasing the existing patch, moving back to In Progress

I've submitted two additional patches to clean up the code a little bit and update unit tests that are now ready for review:

• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1146024
• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1145909

The error preventing the tests from passing was fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/1145255?tab=checks

I've pushed a new patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1145205 without the "Depends-On" annotations (all the referenced aptches are already merged), updated the test so it does not try to update the sites table and it still makes the CirrusSearch tests fail: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-noselenium/96597/console

Tests in CirrusSearch keep failing, likely because both tests in CirrusSearch and in CheckUser modify the Site Store config (CU does so in order to check if links to external users are properly computed. I'm trying to find a workaround in CheckUser tests.

Post-merge for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/1144590 seems stuck (its status is shown as "Pending" for a while), which may be preventing checks for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1137000 from passing, since the later depends on a fix in CirrusSearch tests introduced by the former.

This is currently blocked because of discussions taking place in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1138396 (see also https://wikimedia.slack.com/archives/C05T0U17GNQ/p1746526551676699).

Updated the previous patches and added a new one to fix a test in IPInfo that was failing after the change in core:

• https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1138396
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1137000
• https://gerrit.wikimedia.org/r/c/mediawiki/extensions/IPInfo/+/1140692

In T390834#10765374, @Jdlrobson-WMF wrote:

@hector.arroyo was this resolved by T387119 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1129332 ?

Changes done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1138396 are breaking unit tests from IPInfo and integration tests in CheckUser, so I'm not moving it back to code review yet.

I think the work done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1139193 for this task may already be covered by the patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1138396 we are working on for T389474: CheckUser: Special:GlobalContributions should highlight temporary accounts, since we are moving the logic to determine the CSS classes to apply form CheckUser's GlobalContributions (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1137000) to core.

I've made some changes proposed during the code review in order to move some logic initially part of CheckUser's GlobalContributionsPager into Core's service UserLinkRenderer instead. Although the change in the pager and the service are done, I've not updated the tests yet, which are now failing. Therefore, I'm moving this back to "In Progress".

As of today, the patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1131749 for trimming whitespaces when present in the URL has been merged: URLs like https://en.wikipedia.org/w/index.php?title=Special%3AContributions&target=Krinkle+++ and https://en.wikipedia.org/w/index.php?title=Special%3AContributions&target=++Krinkle now work fine.

Opened https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1134191 to fix this design bug by showing a "No edit summary available" message for external contributions, which makes the message and the "current" badge to be shown aligned with each other in a new line.

A change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/1129332 to fix this has been just merged.

I've removed a fix to prevent the popup revealing the contents behind it and filed T390834: Block messages reveal the contents behind the popup on small screen sizes instead.

I've opened a new patch to trim the usernames used in the autocompletion to the frontend instead: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1133132

As part of this task, we did a refactor that broke the QUnit tests, and fixing them turned out to be a bit tricky.

Changes in the API have been removed from the previous patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1131749/13..17

I'm switching to work on T386639: Special:GlobalContributions does not display edit summaries for edits not made on the central wiki instead of this one, hoping that fixing that will fix this one too.

Overloading the CSS rules for padding-top and line-height for the <span>containing the "current" text seems to solve the issue:

This refers only to accounts listed in Special:GlobalContributions. I've updated the summary and the AC to explicitly mention that the task is to update how the accounts are shown in that page.

An initial, incomplete solution to change how temp accounts are shown can be found at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1126627/49..50, but it was eventully rolled back without being merged back to master as part of that patch. Those changes may serve as a starting point for this task.

Fixing the style used to show temp accounts should be a matter of putting back the changes first commended out in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1126627/49..50 (which were deleted from that patch shortly after)

In T387119#10654381, @kostajh wrote:

I'm not sure about that. The idea with the Drawer component was to appear at the bottom, and there are other tools (see T280330: Support Floating tools and dialogs at the bottom of the viewport) which also do that as well. So if we pin to the top, we'll be doing something inconsistent with the other tools.