@Pchelolo maybe relevant to recent UserGroupManager refactoring?

All recent UserGroupManager changes were reverted. They are postponed until we use more of Authority.

What's a confirmed user?

In T275333#6847289, @Pchelolo wrote:

@Pchelolo maybe relevant to recent UserGroupManager refactoring?

All recent UserGroupManager changes were reverted. They are postponed until we use more of Authority.

Good to know.

What's a confirmed user?

confirmed is a custom group available at all Wikimedia wikis. It has the same rights as autoconfirmed, but can be granted by bureaucrats (and on some wikis, by sysop). A confirmed user is an user that is a member of this group. This group is set in https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L3883.

Just to clarify: it initially worked while logged in. Then Martin asked me to open https://pt.wikipedia.org/wiki/Special:ListUsers/confirmed, which didn't work logged in, but as soon as I refreshed it worked again. It never (recently) worked logged out, though.

...and the information provided in the task description is outdated already, it started to work for my WMF account again. What the hell is happening?

I bet $4 this code in config is to blame:

array_unshift( $wgExtensionFunctions, function () {
	global $wgGroupPermissions;

	$wgGroupPermissions['confirmed'] = $wgGroupPermissions['autoconfirmed'];
	$wgGroupPermissions['confirmed']['skipcaptcha'] = true;
} );

This is from the same series of bugs flagged revisions is suffering from - something somewhere changed and now PermissionManager/UserGroupManager are loaded earlier then extension functions are run. I think it might be CentralAuthPrimaryAuthenticationProvider being loaded and loading permission manager.

T273511 and T273510 will change the initialization sequence in that area, and might magically fix these issues. We were waiting for Authority proposal approval before working on that, I'll make sure to write the code on Monday.

But, in general, this issue will keep reoccurring - mangling permissions from extension function will keep being ignored cause extension functions run very late in the init sequence. We could reset services after running the functions, but that's brutal, that will add a lot to the startup time.

Change 665804 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[operations/mediawiki-config@master] Move confirmed group definition to the end of CS.php

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

In T275333#6847300, @Urbanecm wrote:

In T275333#6847294, @Pchelolo wrote:

[...]

This is from the same series of bugs flagged revisions is suffering from - something somewhere changed and now PermissionManager/UserGroupManager are loaded earlier then extension functions are run. I think it might be CentralAuthPrimaryAuthenticationProvider being loaded and loading permission manager.

Right, that makes sense. I uploaded a patch to move confirmed user definition to the end of CS.php. I'll try to deploy it on Monday, and let's see if it works.

Actually...that will make the code run before extensions are inited, thus bringing T213003: Autoconfirmed rights set by extensions are out of sync with confirmed back. Meh... Unsure how to fix it config-only.

Yeah. Most likely. I don't think a config-only solution exist here. I'll try to get the fixes I mentioned in on Monday so that we could test soon. I don't think identifying and reverting the change that caused init sequence to shift earlier is possible at this point.

Change 665804 abandoned by Urbanecm:
[operations/mediawiki-config@master] Move confirmed group definition to the end of CS.php

Reason:

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

Mentioned in SAL (#wikimedia-operations) [2021-03-17T23:40:18Z] <urbanecm@deploy1002> Synchronized wmf-config/CommonSettings.php: 5c14e7d2045f0905f7e85b249e821bbe8d69c600: Define confirmed group in MediaWikiServices hook (T275334, T277704, T275310, T275333) (duration: 01m 08s)