For some reason admins in ruwiki can't add or remove users in 'autoeditor'.

If I run query meta siteinfo, then I can't see 'autoeditor' in result;

<group name="sysop">
<add>
<group _idx="0">rollbacker</group>
<group _idx="2">uploader</group>
<group _idx="3">closer</group>
<group _idx="4">filemover</group>
<group _idx="5">suppressredirect</group>
<group _idx="6">ipblock-exempt</group>
<group _idx="7">editor</group>
</add>
<remove>
<group _idx="0">rollbacker</group>
<group _idx="2">uploader</group>
<group _idx="3">closer</group>
<group _idx="4">filemover</group>
<group _idx="5">suppressredirect</group>
<group _idx="6">ipblock-exempt</group>
<group _idx="7">editor</group>
</remove>
</group>

But in wmf-config/InitialiseSettings.php:

wgAddGroups' => [
'+ruwiki' => [
		'sysop' => [ 'rollbacker', 'autoeditor', 'uploader', 'closer', 'filemover', 'suppressredirect' ],
		'bureaucrat' => [ 'arbcom', 'engineer' ], // T51334, T144599
	]
]

See also T229596

Hello. I think, there is no need to rename anything. First, to implement topic-starter's idea, it would be enough to restore autoreview group in ruwiki, that is, comment out this single line in wmf-config/flaggedrevs.php:

unset( $wgGroupPermissions['autoreview'] ); // T229596

Then the rest, i.e. moving users to this group, changing interface messages etc., can be done by local admins.

But this is cumbersome, and I believe there is another, easier way to overcome the autoeditor problem. Since for some reason the settings from flaggedrevs.php are not loaded sometimes, we just need to set autoeditor group in wmf-config/InitialiseSettings.php, along with other custom ruwiki groups. Since these groups work well, autoeditor should then work, too. Here is the proposed patch:

--- a/InitialiseSettings.php
+++ b/InitialiseSettings.php
@@ -10253,6 +10253,10 @@
 		'rollbacker' => [ 'rollback' => true ], // T264147
 	],
 	'+ruwiki' => [
+		'autoeditor' => [
+			'autoreview' => true,
+			'autoconfirmed' => true,
+		],
 		'arbcom' => [ // T51334
 			'abusefilter-log-detail' => true,
 			'browsearchive' => true,

Of course, this is not a true solution, just a hack to make it work. I've done a small investigation and it seems that some servers have their configuration broken. The api request posted above by DonRumata yields different results for different users, and we know that users are routed to different servers according to geographical location. And this is not just flaggedrevs bug, because confirmed group (fortunately not used at ruwiki) is also shown differently in the results of this api request.

@Urbanecm and other developres - will this task be completed, in any way? Sorex's patches can work too.

Change 674946 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Do not remove autoreview group

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

Change 674947 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Do not allow sysops to modify users in autoeditor group

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

Change 674946 merged by jenkins-bot:
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Do not remove autoreview group

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

Mentioned in SAL (#wikimedia-operations) [2021-03-25T18:45:16Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: dcfb7feaace1f397169e5e1bab7efd4e5f605a0f: ruwiki: flaggedrevs: Do not remove autoreview group (T275337) (duration: 01m 14s)

Change 674947 merged by jenkins-bot:
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Do not allow sysops to modify users in autoeditor group

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

Change 674950 had a related patch set uploaded (by Urbanecm; author: Urbanecm):
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Delete autoeditor group

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

Mentioned in SAL (#wikimedia-operations) [2021-03-25T18:49:10Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: 39cd4f15a3900783ac0e9a213004a28f18298a23: ruwiki: flaggedrevs: Do not allow sysops to modify users in autoeditor group (T275337) (duration: 01m 09s)

Mentioned in SAL (#wikimedia-operations) [2021-03-25T18:50:23Z] <Urbanecm> mwscript migrateUserGroup.php --wiki=ruwiki 'autoeditor' 'autoreview' # T275337

Change 674950 merged by jenkins-bot:
[operations/mediawiki-config@master] ruwiki: flaggedrevs: Delete autoeditor group

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

Mentioned in SAL (#wikimedia-operations) [2021-03-25T18:59:48Z] <Urbanecm> mwscript migrateUserGroup.php --wiki=ruwiki 'autoeditor' 'autoreview' finished (T275337)

Mentioned in SAL (#wikimedia-operations) [2021-03-25T19:01:38Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: ce7d2d7a51bd2e3717b4de7b2f7e8ae427c221ad: ruwiki: flaggedrevs: Delete autoeditor group (T275337) (duration: 01m 06s)

Mentioned in SAL (#wikimedia-operations) [2021-03-25T19:04:47Z] <urbanecm@deploy1002> Synchronized wmf-config/flaggedrevs.php: ce7d2d7a51bd2e3717b4de7b2f7e8ae427c221ad: ruwiki: flaggedrevs: Delete autoeditor group (T275337) (duration: 01m 08s)

In T275337#6873258, @Sorex wrote:

Hello. I think, there is no need to rename anything. First, to implement topic-starter's idea, it would be enough to restore autoreview group in ruwiki, that is, comment out this single line in wmf-config/flaggedrevs.php:

unset( $wgGroupPermissions['autoreview'] ); // T229596

Then the rest, i.e. moving users to this group, changing interface messages etc., can be done by local admins.

We have a script (migrateUserGroup.php) to handle the membership migration, so that's not an issue. I've "renamed" the group (ie. reviwed the default group by removing the line you mention, disallowing sysops to touch it [so membership does not change], running the script, which reassigned the users from autoeditor to autoreview, and then deleting the autoeditor group). Since I'm unaware of how the group should be called in the interface messages, I'd prefer if you could do that. Do let me know if you have any questions.

But this is cumbersome, and I believe there is another, easier way to overcome the autoeditor problem. Since for some reason the settings from flaggedrevs.php are not loaded sometimes, we just need to set autoeditor group in wmf-config/InitialiseSettings.php, along with other custom ruwiki groups. Since these groups work well, autoeditor should then work, too.

The reason is actually known: T275334. What's not so easy is how to fix that. Feel free to join the discussion in the task if you wish. Moving to IS.php would probably fix it without moving, at the cost of having flaggedrevs settings split across multiple places. Moving parts of ruwiki config out of extension registration function should make it work as well. But, since the group was already renamed, it doesn't ultimately matter much.

Here is the proposed patch:

--- a/InitialiseSettings.php
+++ b/InitialiseSettings.php
@@ -10253,6 +10253,10 @@
 		'rollbacker' => [ 'rollback' => true ], // T264147
 	],
 	'+ruwiki' => [
+		'autoeditor' => [
+			'autoreview' => true,
+			'autoconfirmed' => true,
+		],
 		'arbcom' => [ // T51334
 			'abusefilter-log-detail' => true,
 			'browsearchive' => true,

Of course, this is not a true solution, just a hack to make it work. I've done a small investigation and it seems that some servers have their configuration broken.

It's not really caused by having different configuration on different hosts, it's that the processing is not behaving in the same way all the time. Root cause is T275334 (and in the wider sense, using extension registration functions at all)..

The api request posted above by DonRumata yields different results for different users, and we know that users are routed to different servers according to geographical location.

FTR, only the caching layer is affected by that, everyone reaches the same application servers. Caching layer is not causing this, application layer is (linking T275334 one more time).

And this is not just flaggedrevs bug, because confirmed group (fortunately not used at ruwiki) is also shown differently in the results of this api request.

That should be fixed already with 5c14e7d2045f. If not, shout at me ;).

Thanks a lot, now it works. Confirmed is fixed too, I confirm :)

FTR, only the caching layer is affected by that, everyone reaches the same application servers. Caching layer is not causing this, application layer is (linking T275334 one more time).

It's strange... I tried that request many times, logged in two different accounts and logged out, and from different devices, — always with the same result. But some other users had different result.
Anyway, now it behaves as expected.