There is some additional complication for logins that are successful, as we need to call the API on the page loaded after the login has occurred. In most cases, that is the page specified in the 'return to' part of the URL. Plus, for MediaWiki-extensions-CentralAuth installations there may be some level of redirecting around to sign-in to other wiki farms.

I'm starting work on this again.

This has been done with help from Kosta.

This isn't actually broken on the master branch. It seems that in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1087934/9 the test was using array_rand, and the behaviour that causes the test failure wasn't seen until a few test runs in.

Interestingly, the test fails for me locally when I have https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1087934/9 checked out. Maybe something changed in between the last test run on that patch and gate-and-submit-wmf in another repository that broke things?

Strangely it passes on the gated extensions test run, but fails on the other (e.g. https://integration.wikimedia.org/ci/job/wmf-quibble-vendor-mysql-php74/23728/consoleFull#console-section-0 vs https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-noselenium/52895/consoleFull#console-section-0). If not related to parallel testing, perhaps it's an extension that CheckUser depends on but is not a gated extension that is conflicting here?

In T371167#10296499, @Jdforrester-WMF wrote:

Do we have a target for "good enough" so we can close this, or is it doomed to be forever open? :-)

Hmm. I don't have anything specific in mind. Perhaps at 44% it would definitely be resolved, and possibly sooner if I don't see any other maintenance scripts that are not too complicated to write tests for.

In T379065#10294968, @JJMC89 wrote:

Unless thee are objections, I will add all the GSs to global-temporary-account-viewer and remove checkuser-temporary-account from global-sysop.

Please go ahead and do this. Thanks.

This probably does need a config patch to prevent auto-promotion on WMF wikis, but we need to wait until the CentralAuth patch is on all wikis.

It seems that virtual-globaljsonlinks is not defined in mediawiki-config, so I'd say that is the first step (given that this is a shared table and shouldn't be on the local wiki).

A solution is to have the voting action create a log entry, which like all other kinds of log entries, populates the CheckUser result tables.

Closing this as invalid, given that it appears that this was fixed by running composer update --no-dev. Re-open if this was not fixed.

Fix has been +2'd. Should be ready for QA shortly on the beta cluster / locally.

Found the cause: https://gerrit.wikimedia.org/g/mediawiki/core/+/refs/changes/30/1084130/11/includes/widget/NamespaceInputWidget.php#42

This was working at commit e438c515bf9390dcb8cb2049298deb0f087439bb and is broken on the master branch. It's not broken when I disable JavaScript.

I guess what is left is to update site config to hide the checkuser-temporary-account-viewer group.

In T377829#10283873, @dom_walden wrote:

@mszabo I have in my LocalSettings.php:

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

As a new user, I make an edit. In Special:RecentChanges, I see <user> was automatically promoted from (none) to temporary account IP viewer.

I have tried looking at the logs but I cannot work out why this is happening.

It seems that the config name was typed incorrectly in the comment above. It is named $wgAutopromoteOnceRCExcludedGroups.

Schema-change-in-production ticket is T378747

Adding DBA per https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change point 2

You can follow the steps in the task description or in T378091 for QA.

This can be made public now too.

Thanks. Resolving.

In T377760#10278791, @UOzurumba wrote:

In T377760#10276640, @Dreamy_Jazz wrote:

Adding User-notice. This ticket will enable the global autoblocks feature on WMF wikis (parent epic task T368949 describes the feature and should probably the one to link). We plan to do this today.

Thank you! I will add this to the current Tech News with the following wording:
Wikimedia project contributors will now notice that autoblocked users can no longer make subsequent edits in any Wikimedia project once logged out of their temporary accounts. Previously, blocked temporary accounts could make another edit in other projects, causing the auto-creation of another temporary account. Also, autoblocks could only work for local blocks. With this improvement, autoblocks can globally block a temporary account user and prevent them from further account creation in the Wikimedia projects.1

Hi. I'm not sure that this wording is accurate to what is being done in this ticket and the parent epic. I put some suggested wording on a WMF google doc.

I'll merge the wmf.28 backport later, as a flaky selenium test caused failures and meant I can't be around for when it does merge.

In T378563#10277077, @dom_walden wrote:

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

Ah, I see. I'll make a fix for that.

MediaModeration jobs have gone back to normal processing.

Adding User-notice. This ticket will enable the global autoblocks feature on WMF wikis (parent epic task T368949 describes the feature and should probably the one to link). We plan to do this today.

This is a bug from core from what I can tell.

In T375751#10273311, @fnegri wrote:

@Dreamy_Jazz Ben is out this week, I will assign to myself and double check that the analytics replicas are up to date.

Thanks!

Are we sure that the replicas have been fully updated? My last understanding of this is that not all the wiki replica DBs were properly updated.