I can filter on tags.

I see that we are displaying and linking to local namespaces correctly, even custom ones.

I can no longer reproduce the bug.

In T374196#10360259, @MusikAnimal wrote:

I wasn't able to repro with or without the 2017 editor. If could file a bug that'd be awesome. Thanks Dom!!

In T379215#10360042, @HMonroy wrote:

@dom_walden looks like the issue you found has magically been fixed. Can you confirm please?

I cannot reproduce the bug for either named and temporary accounts.

Thanks. I cannot reproduce the original bug nor T378350#10331103.

In T378353#10331761, @Dreamy_Jazz wrote:

@dom_walden Thanks for finding this. I have reproduced this but in a way that I think means that it is the intended behaviour. I say this because:

• We do not extend the expiry of global autoblocks when the parent global block has their expiry lengthened. This is the expected behaviour as this matches what is done for local autoblocks.
• When an IP is then retroactively autoblocked it updates the expiry such that the expiry for the last used IP address will be 24 hours.

This means that it appears that the block modification has updated the expiry for one of the global autoblocks to 24 hours while leaving the others intact.

Thanks. I cannot reproduce that bug anymore.

Hide username

I can confirm the acceptance criteria appear to be met.

What we have done appears consistent with acceptance criteria:

In T379537#10334669, @Samwilson wrote:

This looks like it was fixed as part of T379162, where the target field was changed to treat blur as the same as selecting a value from the dropdown.

I don't think there's anything else remaining, and I can't reproduce this bug now.

We now have a separate table called "Suppressed block log", which appears to only return suppressed block creations and modifications.

In T379106#10350045, @Tchanders wrote:

@dom_walden Does this fix issues you were seeing with getting Special:GlobalContributions to work locally?

In T379049#10348641, @KColeman-WMF wrote:

IP Info isn't a table so it doesn't have pagination? Is the issue that we need to explain that the IP Infobox is showing information for the last used IP address of a temp account?

@HMonroy I am finding that if I load an existing block (Special:Block/<target>) which already has page and/or namespaces set, then when I submit the block the page and namespace input and block type radio is not reset.

I have run this against a few filters. Protected, public filters become public filters. Protected, private filters become private. Unprotected filters are unchanged.

• Remove the "protect" checkbox from the form. (This means a filter can't be protected without protected variables.)
• After clicking save, show a warning with a "protect" checkbox if the filter contains protected variables
• Without checking this box, it is impossible to save the filter

Temporary accounts lead to a validation error ~2024-10 isn't a valid username.

I see:

• Rate of temporary account autocreation (which appears to be a total across all wikis)
• Rate of temporary account autocreation by wiki, account type (looks very similar to the previous graph but broken down by wiki)
• Rate of account creation by wiki (I am not sure what this is showing me, the number of account creations are lower than in the previous two graphs)

@Dreamy_Jazz Should all the parent's autoblocks be updated at the same time? I find that if I have two autoblocks and update the parent block's expiry to be longer than that of the autoblocks, only one autoblock gets its expiry updated (although other fields are updated on all autoblocks).

@Dreamy_Jazz If the autoblock is not pruned as well when re-creating the expired parent block, then the gb_autoblock_parent_id is not updated (but the gb_expiry is). If you then delete the parent block, the autoblock remains.

I see client hints being stored for both failed and successfully logins.

In T326934#10227250, @mszabo wrote:

QA Notes (for r1078969, r1079298)
...

Opening IPInfo popups and infoboxes on testwiki, I see requests made to https://intake-analytics.wikimedia.org/v1/events.

I don't see temp account name suggested on Special:RenameUser.

I no longer see temp users in the suggestions dropdown on Special:EmailUser.

The IPInfo popup now appears above the "Compare selected revisions" button.

Making an API request to action=query&list=abuselog I no longer see the TransactionProfiler warnings.

I submitted a Special:IPInfo request with the agreement checkbox checked. I did not see a TransactionProfiler warning in the logs.

I don't see autocomplete anymore, nor are API requests made in the background.

I also notice that sometimes the These results may be incomplete because you do not have the right to view IP addresses used by temporary accounts at every wiki. is shown twice, presumably if there are multiple wikis you don't have permissions for.

I now see an error message when entering a CIDR range larger than 16 for IPv4 and 32 for IPv6. The two error messages you see are consistent.

We now have a chart for "Rate of page deletions".

I see that we now have a chart called "Revert rate" which has some data in it.

I cannot reproduce the misalignment issues from the description.

In T357482#10301400, @MusikAnimal wrote:

@dom_walden @Bhsd Could I get you to test the scenarios where you saw misalignment once more? It for sure isn't completely resolved, but r1087618 should have helped.

@dmaza I find that sometimes after clearing the target input (by pressing the x or deleting the input) the log tables clear but the counts remain.

@Samwilson A couple of things I have noticed from testing so far:

• letype=suppress will not just include blocks. It will also include things like suppressing a page. If you suppress the page User:<target>, in Special:Block/<target> the Suppressed blocks table will include a row for the suppression of that page.
• The Target column is always blank for me.

I have seen we have an "Active blocks" table which includes the current block. I have tested for named users, temp users, IPs and IP ranges.

I see the block log being updated every time I submit a block successfully.

In T362718#10246272, @dom_walden wrote:

Did we want a limit to the number of pages a user can enter? In the OOUI Special:Block form the limit is 10 pages. I don't remember the reason this number was chosen. @MusikAnimal

Reviewing the Special:Version and configs of the proposed wikis, I came up with this list and include any testing I did:

I have looked at the infobox on Special:Contributions for temporary accounts and for IP addresses.

I have checked that the correct IP is being looked up for revisions, archived revisions and log entries (for the performer).

I cannot reproduce this exception for either the autocreateaccount or createaccount actions.

@Tchanders I am finding for IPv6 that if I enter, for example, /16 I am told The IP range exceeds its maximum range. Allowed range: /19.

I see the namespace select populated with what appear to be the correct namespaces in a few different special pages, including Special:Contributions, Special:Export (with $wgExportFromNamespaces) and Special:MovePage. When submitting the form with a namespace selected it appeared to return results from that namespace.

In T377722#10286560, @Samwilson wrote:

I'm assuming that the description didn't mean to have "not" and say, that when the block is partial and selecting the "User_talk" namespace, "Editing their own talk page" should be hidden since they are being blocked for all User_talk namespace, which includes their own talk page, right?

Yep! That's my understanding too. @dom_walden are we thinking about this correctly, or are things backwards?

I see that https://test.wikipedia.org/wiki/Special:GlobalContributions/127.0.0.1 redirects to https://meta.wikimedia.org/wiki/Special:GlobalContributions/127.0.0.1.

I see that on https://meta.wikimedia.org/wiki/Special:ListGroupRights the rights checkuser-temporary-account and checkuser-temporary-account-no-preference do not appear at all.

On testwiki:

• sysop has abusefilter-access-protected-vars but does not have abusefilter-protected-vars-log
• checkuser has abusefilter-protected-vars-log but does not have abusefilter-access-protected-vars

I did not see an exception when importing an article which had an IP edit which added a category.

In T378179#10279507, @gerritbot wrote:

Change #1084130 merged by jenkins-bot:

[mediawiki/core@master] Support 'include' parameter in namespace select inputs

https://gerrit.wikimedia.org/r/1084130

I don't see an RC entry when I set:

• $wgAutopromoteOnceRCExcludedGroups = [ 'checkuser-temporary-account-viewer' ]; or
• $wgAutopromoteOnceRCExcludedGroups = [ 'checkuser-temporary-account-viewer', 'captain' ];

While testing T365743, I saw AbuseFilter logs being recorded in the CheckUser temporary account log on my local docker environment.

Moving to Done as this is just a copy change to en.json.

The namespaces listed are:

all
(Main)
Talk
User
User talk
Mediawiki
Mediawiki talk
File
File talk
MediaWiki
MediaWiki talk
Template
Template talk
Help
Help talk
Category
Category talk

@mszabo I have in my LocalSettings.php:

$wgAutopromoteOnce = [
	'onEdit' => [
		'checkuser-temporary-account-viewer' => [ APCOND_EDITCOUNT, 0 ],
	]
];
$wgAutopromoteRCExcludedGroups = [ 'checkuser-temporary-account-viewer' ];
$wgAutopromoteOnceLogInRC = true;

@mszabo I see that Special:GlobalContributions still makes the API request api.php?action=query&format=json&list=allusers&auprefix=<search>&aulimit=10&auexcludenamed=1&auexcludetemp=1. If it is excluding temp and named users, I assume this will never return anything. Should we just stop making the request at all and save some bandwidth?

I used the API to globally block a temp and named user which did not exist on the local wiki.

I cannot reproduce the bug in the description.

I cannot reproduce the exception from the description, and autoblocks do correctly block account creations.

I can no longer reproduce this bug.

I cannot reproduce the bug.

@Dreamy_Jazz I think this change means autoblocks won't block account creation, even when they should.

I have found a circumstance where an autoblock whose parent has been pruned (because it has a shorter expiry) can lead to an exception: T378447.

I wrote a script to create a number of global blocks with different block params and checking that an autoblock is always created (with exceptions that are consistent with local autoblocks).

I have not been able to modify a global autoblock.