@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.

I have not observed any global autoblock which includes the target.

In T375393#10257016, @Reedy wrote:

Is this for any captcha type (or at least, not just the math examples you're showing)? I'm guessing from you saying you tested it on https://en.wikipedia.beta.wmflabs.org too that it is, but want to make sure

I inserted an entry to cu_log with a cul_target_text=1.2.00.00/16. Then I looked at the entry in Special:CheckUserLog. The logs showed the query GlobalBlockLookup was making is correct (as far as I can tell):

[rdbms] MediaWiki\Extension\GlobalBlocking\Services\GlobalBlockLookup::getGlobalBlockingBlock [0.214ms] mariadb-main: SELECT  gb_id,gb_address,gb_target_central_id,gb_by_central_id,gb_by_wiki,gb_reason,gb_timestamp,gb_anon_only,gb_expiry,gb_range_start,gb_range_end,gb_create_account,gb_enable_autoblock,gb_autoblock_parent_id  FROM `globalblocks`    WHERE ((gb_expiry > '20241022105107' AND (gb_range_start LIKE '0102%' ESCAPE '`' AND gb_range_start <= '01020000' AND gb_range_end >= '0102FFFF')))

I tested looking up a number of IPs via Special:GlobalContributions and checking that a row had been added for the IP in the logging table. It has log_type=checkuser-temporary-account and log_action=view-temp-accounts-on-ip-global. This is regardless of whether Special:GlobalContributions actually returned any results.

Going to https://test.wikipedia.org/wiki/Special:GlobalContributions as my staff account redirects to https://meta.wikimedia.org/wiki/Special:GlobalContributions.

Querying the API[1] can trigger a lot of logs being inserted. I did this and checked that every temporary user whose AbuseFilter log was included in the API response also had a log generated in the logging table.

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