Page MenuHomePhabricator

FlaggedRevs: Automatic user promotion stopped working on some wikis on June 24, 2019
Closed, ResolvedPublic

Description

As you can see in the log, the automatic user promotion which gives users autoreview/review right has stopped working on June 24, 2019. The last automatic promotion was done shortly before 2400 local time.

Wikis where it stopped working

  • dewiki
  • plwiki
  • enwikibooks

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Masumrezarock100 added a comment.EditedDec 14 2019, 2:35 AM

@Zache Could you confirm that auto-promotion stopped working on Finnish Wikipedia?

Zache added a comment.Dec 14 2019, 2:52 AM

@Zache Could you confirm that auto-promotion stopped working on Finnish Wikipedia?

Finnish Wikipedia is using manual promotion for autoreview and editor user groups, so this cannot be tested with fiwiki.

Zache added a comment.EditedDec 14 2019, 3:40 AM

In plwiki it stopped working also at 23:17, 24 June 2019 ( log )

Zache updated the task description. (Show Details)Dec 14 2019, 10:17 AM

Obviously not a single wiki issue. Auto-promotion stopped working on enwikibooks and some other wikis as well. On English Wikibooks, the last auto-promotion occurred on 20 June 2019, two days before it stopped working on dewiki. I am inclined to believe it's an issue with the extension itself rather than a site configuration regression. I do not know about other wikis. Could anyone reach out to wikis where this extension is deployed/enabled to see if they are facing the same problem?

Around this date, the Wikimedia global FlaggedRevs configuration has been reorganiszed. So it is much more probable to actually be a site configuration issue.

Masumrezarock100 added a comment.EditedDec 15 2019, 11:23 PM

Around this date, the Wikimedia global FlaggedRevs configuration has been reorganiszed. So it is much more probable to actually be a site configuration issue.

Hmm. So when the person who caused this regression is going to fix it? Does it really take over 6 months to fix it?

Zache added a comment.EditedDec 17 2019, 8:13 AM

Tested that flaggedrevs_promote is still updated

MariaDB [dewiki_p]> select * from flaggedrevs_promote where frp_user_id=1374006;

+-------------+------------------------------------------------------------------------------------------------+
| frp_user_id | frp_user_params                                                                                |
+-------------+------------------------------------------------------------------------------------------------+
|     1374006 | uniqueContentPages=3083097,6296562,1386366
totalContentEdits=3
editComments=15
revertedEdits=1 |
+-------------+------------------------------------------------------------------------------------------------+
1 row in set (1.58 sec)

And after edit: https://de.wikipedia.org/w/index.php?title=Kabinett_Marin&diff=prev&oldid=194975694

MariaDB [dewiki_p]> select * from flaggedrevs_promote where frp_user_id=1374006;
+-------------+---------------------------------------------------------------------------------------------------------+
| frp_user_id | frp_user_params                                                                                         |
+-------------+---------------------------------------------------------------------------------------------------------+
| 1374006 | uniqueContentPages=3083097,6296562,1386366,11066484
totalContentEdits=4
editComments=16
revertedEdits=1 |
+-------------+---------------------------------------------------------------------------------------------------------+

This means that either wgFlaggedRevsAutopromote OR wgFlaggedRevsAutoconfirm
is defined when FlaggedRevsHooks.php : onPageContentSaveComplete() is called.

Hi @DannyS712 Question: can abuse filter be used for autopromotion? If so this could be a temporary solution.

Hi @DannyS712 Question: can abuse filter be used for autopromotion? If so this could be a temporary solution.

No, it cannot be, sorry

Hi @DannyS712 Question: can abuse filter be used for autopromotion? If so this could be a temporary solution.

No, it cannot be, sorry

Too bad. Only demotion of existing autoconfirmed accounts/restoring autoconfirmed starus are allowed, it seems.

Zache added a comment.Dec 24 2019, 9:32 AM

If we just want quickfix for autopromote with some features missing then it editor/autoreview/reviewer groups could just added via wmgAutopromoteExtraGroups or wmgAutopromoteOnceonEdit in InitialiseSettings.php

Some notes.

If I looked correctly dewiki's $wgFlaggedRevsAutoconfirm variable wasn't changed in 24 June 2019 in config rewrite. It was also already set to false at extension.jsonbefore the config change. Based on deployment calendar the mediawiki software update was 27.6 so it is not explanation either. Only bigger change was wrapping wmf-config/flaggedrevs.php was to function which was called from wgExtensionFunctions.

Is it possible to make a quick and dirty solution: Is it possible to get a list of users waiting for this rights manually and then we only need an admin who sets the rights. Solution seems to be very urgent

Zache added a comment.EditedFeb 23 2020, 9:58 AM

Is it possible to make a quick and dirty solution: Is it possible to get a list of users waiting for this rights manually and then we only need an admin who sets the rights. Solution seems to be very urgent

If it is for dewiki, then it seems that you have manually added the users to the editors group, but there is missing 49 users from autoreview group. Note this doesn't check benchmarks (number of "spread out" edits) but blindly calculates the number of the unique days with edits. Actual results are behind the quarry links.

  • Dewiki autopromote list for editors: Quarry 42368 ( 0 users )
  • Dewiki autopromote list for autoreviews: Quarry 42371 (49 users )
USE dewiki_p;

SET @editComments = 20;
SET @uniqueContentPages = 8;
SET @totalContentEdits = 150;
SET @reviewedEdits = 50;
SET @revertedEditsRatio = 1;
SET @usergroup="editor";
SET @userregistratioage=30;
SET @unique_days_with_edits=21;
-- newer blocked is always true
-- newer demoted is always true

SELECT * FROM (
SELECT tt.*, count(distinct(floor(rev_timestamp/1000000))) as unique_days_with_edits FROM (
SELECT * FROM (
SELECT 
    user_name,
	frp_user_id, 

     -- frp_editComments
     IF (frp_user_params LIKE "%editComments%", CAST(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?editComments=(.*?);.*$", "\\1") AS UNSIGNED INTEGER), 0) as frp_editComments,

     -- frp_uniqueContentPages
     IF (frp_user_params LIKE "%uniqueContentPages%", (1+length(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?uniqueContentPages=(.*?);.*$", "\\1")) - length(replace(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?uniqueContentPages=(.*?);.*$", "\\1"), ",", ""))), 0) as frp_uniqueContentPages, 

    -- frp_totalContentEdits
    IF (frp_user_params LIKE "%totalContentEdits%", CAST(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?totalContentEdits=(.*?);.*$", "\\1") AS UNSIGNED INTEGER), 0) as frp_totalContentEdits,

    -- frp_reviewedEdits
     IF (frp_user_params LIKE "%reviewedEdits%", CAST(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?reviewedEdits=(.*?);.*$", "\\1") AS UNSIGNED  INTEGER), 0) as frp_reviewedEdits,

    -- frp_revertedEdits
    IF (frp_user_params LIKE "%revertedEdits%", CAST(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?revertedEdits=(.*?);.*$", "\\1") AS UNSIGNED  INTEGER), 0) as frp_revertedEdits,

    -- frp_demoted
    IF (frp_user_params LIKE "%demoted%", CAST(regexp_replace(replace(concat(frp_user_params, ";"), "\n", ";"), ".*?demoted=(.*?);.*$", "\\1") AS  UNSIGNED  INTEGER), 0) as frp_demoted,

    user_editcount,
    datediff(now(), str_to_date(user_registration, "%Y%m%d%H%i%S")) as days_since_registration
FROM 
	flaggedrevs_promote,
    user
  LEFT JOIN (SELECT ufg_user FROM user_former_groups WHERE ufg_group IN (@usergroup, "editor", "bot") GROUP BY ufg_user) as ufg ON ufg_user=user_id 
  LEFT JOIN (SELECT ug_user FROM user_groups WHERE ug_group IN (@usergroup, "editor", "bot") GROUP BY ug_user) as ug ON ug_user=user_id 
WHERE
    frp_user_id = user_id 
	AND ufg_user IS NULL
    AND ug_user IS NULL
    AND user_editcount > @totalContentEdits
    AND user_registration IS NOT NULL
    AND datediff(now(), str_to_date(user_registration, "%Y%m%d%H%i%S")) > @userregistratioage
) AS t
WHERE 
	frp_editComments >  @editComments
    AND frp_uniqueContentPages > @uniqueContentPages
    AND frp_totalContentEdits > @totalContentEdits
    AND frp_reviewedEdits > @reviewedEdits
    AND frp_demoted = 0
	AND (frp_revertedEdits>frp_totalContentEdits) < @revertedEditsRatio 
) AS tt
	LEFT JOIN actor_logging ON tt.frp_user_id=actor_user
    LEFT JOIN logging_userindex ON replace(actor_name, " ", "_")=log_title AND log_type="block"
    LEFT JOIN revision_userindex ON actor_id = rev_actor   
WHERE 
    log_actor IS NULL
GROUP BY frp_user_id
) AS ttt
WHERE unique_days_with_edits > @unique_days_with_edits

Thanks a lot. Not so much. Nevertheless: Is there any admin willing to give the rights manually for this 49 persons?

Krd removed a subscriber: Krd.Feb 23 2020, 11:04 AM
Zache added a comment.Feb 23 2020, 1:29 PM

Thanks a lot. Not so much. Nevertheless: Is there any admin willing to give the rights manually for this 49 persons?

No idea but it would be a good idea to give barnstars to admins who are doing right now because numbers would be bigger if they would not be giving the user rights manually.

Zache added a comment.EditedFeb 23 2020, 3:07 PM

@Reedy I hava an idea why the autopromote is broken.

In the end of the FlaggedRevs.php / after mediawiki-extensions-FlaggedRevs/extension.json is parsed the value of the wfExtensionFunction is next

$wfExtensionFunctions: [
    "FlaggedRevsHooks::onExtensionFunctions",                 // wfLoadExtension( 'FlaggedRevs' ); ->  mediawiki-extensions-FlaggedRevs/extension.json
    "FlaggedRevs settings function ..."                       // defined in FlaggedRevs.php  
],

Order of the values is because

  • values are merged with default mergeStrategy 'array_merge' : $GLOBALS[$key] = array_merge( $val, $GLOBALS[$key] ); ( ExtensionRegistry.php::exportExtractedData() )
  • Array_merge() merges the elements of one or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array.

So when Setup.php loads queued extensions it will run FlaggedRevsHooks::onExtensionFunctions(). This will run the FlaggedRevsSetup::setAutopromoteConfig(). As the FlaggedRevs.php configuration function has not yet been executed the setAutopromoteConfig() will run using the default values from mediawiki-extensions-FlaggedRevs/extension.json

"FlaggedRevsAutopromote": {
   "description": "Define when users get automatically promoted to Editors. Set as false to disable. Once users meet these requirements they will be promoted, unless previously demoted.",
   "value": false
},
"FlaggedRevsAutoconfirm": {
   "description": "Define when users get to have their own edits auto-reviewed. Set to false to disable. This can be used for newer, semi-trusted users to improve workflow. It is done by granting some users the implicit 'autoreview' group.",
   "value": false
},

And as $wgFlaggedRevsAutoconfirm and $wgFlaggedRevsAutopromote are false in FlaggedRevsSetup::setAutopromoteConfig() the wgAutopromoteOnce is not defined..

public static function setAutopromoteConfig() {
   global $wgFlaggedRevsAutoconfirm, $wgFlaggedRevsAutopromote;
   global $wgAutopromoteOnce, $wgGroupPermissions;
   ...
   if ( is_array( $wgFlaggedRevsAutoconfirm ) ) {
      ...
      $wgAutopromoteOnce['onEdit']['autoreview'] = $criteria;
   }
 
   if ( is_array( $wgFlaggedRevsAutopromote ) ) {
      ...
      $wgAutopromoteOnce['onEdit']['editor'] = $criteria;
   }
}
Reedy added a comment.Feb 23 2020, 3:09 PM

FR config is complex :(

We can move setAutopromoteConfig elsewhere/later...

Stuff like this was part of the reason I added the extension function in mediawiki-config, to try and delay the setup of some of the stuff after ext-reg-ification

Reedy added a comment.Feb 23 2020, 3:15 PM

If you want propose patch(es), that’d be appreciated. I can look later tonight/tomorrow

Brainswiffer added a comment.EditedFeb 24 2020, 6:21 AM

@Zache
You wrote Dewiki autopromote list for editors: Quarry 42366 ( 0 users )
Different to the 2. Quarry there is no source text when you call it?

Zache added a comment.Feb 24 2020, 8:01 AM

Sorry, it had wrong quarry id. https://quarry.wmflabs.org/query/42368 is correct one.

Man77 awarded a token.Mar 8 2020, 10:45 AM
Man77 added a subscriber: Man77.

I think we should call onExtensionFunctions() directly at the end of the extension function defined in flaggedrevs.php and remove it from extension.json altogether.

@Reedy @Zache What do you think?

Reedy added a comment.Mar 10 2020, 2:01 PM

I think we should call onExtensionFunctions() directly at the end of the extension function defined in flaggedrevs.php and remove it from extension.json altogether.

@Reedy @Zache What do you think?

How does that help 3rd party wikis?

How does that help 3rd party wikis?

... Not at all.

Why is the config for the WMF-Wikis in flaggedrevs.php wrapped into an extension function anyway? In the deployment instructions of FlaggedRevs for other wikis the config is supposed to go into LocalSettings.php without being wrapped like this.

Aklapper renamed this task from FlaggedRevs: Automatic user promotion stopped working on some wikis on June 24 to FlaggedRevs: Automatic user promotion stopped working on some wikis on June 24, 2019.Mar 10 2020, 3:14 PM
Reedy added a comment.EditedMar 10 2020, 3:22 PM

Why is the config for the WMF-Wikis in flaggedrevs.php wrapped into an extension function anyway? In the deployment instructions of FlaggedRevs for other wikis the config is supposed to go into LocalSettings.php without being wrapped like this.

Because FlaggedRevs config is frankly, a mess. It was an attempt to work around some other issues after ext-reg migration

If we fix the dependancy hell/expectation that things run in a specific order, it can almost certainly be removed

AND (frp_revertedEdits>frp_totalContentEdits) < @revertedEditsRatio

Shouldn't there be a '/' instead of '>' ?

One year from the malfunction, still not working.

Wargo added a comment.Jul 23 2020, 8:00 PM

Why these config variables can't be moved outside of wgExtensionFunctions, and, for example, before wfLoadExtension? They are just variables. They should be accessible to all FR's functions when executing. If not, what would be executing steps when opening wiki?

Example of execution steps (and code order):

  1. Create variables $wgFlaggedRevsAutopromote etc.
  2. Load and execute extension Flagged Revs
  3. It runs onExtensionFunctions which runs setAutopromoteConfig
  4. setAutopromoteConfig can access declared config in step 1

If not, what is the difference with other extensions?

Zache added a comment.Mon, Sep 7, 9:22 AM

T262196 seems to be related to same root cause too.

Folks from Polish Wikipedia asked me to have a look at this…

Why these config variables can't be moved outside of wgExtensionFunctions, and, for example, before wfLoadExtension? They are just variables. They should be accessible to all FR's functions when executing. If not, what would be executing steps when opening wiki?

This indeed looks like an obvious thing to attempt, and I don't see why no one tried it. I guess I'll do it.

I'm not sure whether this will actually fix the issue. There are some other things going on and I'm not sure in what order they happen. (For example: the FlaggedRevs extension function that reads $wgFlaggedRevsAutoconfirm and $wgFlaggedRevsAutopromote only uses it to set the $wgAutopromoteOnce variable, and the code reading $wgAutopromoteOnce in core might run before that…)

It looks like autopromote conditions are only checked when the user makes an edit, so even if this works, we won't immediately see a huge number of autopromotions, only after each user saves an edit.

Change 627332 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] flaggedrevs: Move setting of wgFlaggedRevsAutopromote and wgFlaggedRevsAutoconfirm out of wgExtensionFunctions

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

Change 627332 merged by jenkins-bot:
[operations/mediawiki-config@master] flaggedrevs: Move setting of wgFlaggedRevsAutopromote and wgFlaggedRevsAutoconfirm out of wgExtensionFunctions

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

Mentioned in SAL (#wikimedia-operations) [2020-09-14T18:15:17Z] <urbanecm@deploy1001> Synchronized wmf-config/flaggedrevs.php: 720e6cbfe1800fe32dc65c209240ba08706dbb17: flaggedrevs: Move setting of wgFlaggedRevsAutopromote and wgFlaggedRevsAutoconfirm out of wgExtensionFunctions (T237191) (duration: 00m 56s)

I'm watching the user rights logs on the wikis with FlaggedRevs enabled to see if this change has an effect.

Looks like two lucky users on de.wp were autopromoted already: https://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&type=rights&subtype=autopromote

It should work for other wikis as well, I'll close this task later today when I can confirm that (autopromotions only happen when the user makes an edit).

There are some complicated rules about frequency of recent edits over time and I honestly don't know if you should have been autopromoted. But since this was the first edit since March, it might be correct according to the configuration.

Udo_T added a comment.EditedMon, Sep 14, 8:59 PM

In dewiktionary we have the user "Beitrag50330" with over 360 contributions in NS 0, see here.

All criteria for "autoreview" (passiver Sichter) would be met:
1.)> 60 days registered
2.) well over 250 edits in the namespace 0
3.)> 50 different pages edited
and 4.) never blocked

Best regards
Udo T.

Thanks for your work, matmarex! I do not think that the problem is solved, because this autopromotes have just give users with review-right the autoreview-right. Normally a user with review should have autoreview as well because this is given before the review-right. On the other hand autoreview is already included in review.
It seem like there have been no autopromotes to users without review. (On german wikipedia).

Udo_T added a comment.EditedMon, Sep 14, 9:19 PM

@Ameisenigel: but take a look at user "Wilkibur", see here.

@Udo_T Thank you for the example, indeed it looks like that user meets the criteria.

My current guess is that while the configuration was broken, FlaggedRevs was not tracking the data about user's edit frequency required for the 'spacing' and 'benchmarks' criteria, and autopromotion is going to be wonky for the next few days/weeks because of that.

It is definitely working in some cases now. 21 users have received the user rights on 3 wikis so far today:

de.wikipedia.org19log
de.wiktionary.org1log
pl.wikipedia.org1log

@Udo_T I have not seen this one, but you are right. With "Drawback" we have one user who was autopromoted to reviewer as well. Seems to work good!

@matmarex. Ok, now I see it. The user "Wilkibur" in dewikipedia did many edits before July 2019, the time when "autopromote" no longer worked.

But the user "Beitrag50330" in the dewikitionary have only contributions since September 2019.

If I understand you correctly, "autopromote" will start counting the contributions from today for the user "Beitrag50330". And that's probably why it doesn't work for him yet.

Best regards
Udo T.

Count_Count added a comment.EditedTue, Sep 15, 6:01 AM

I have written a tool to check the autopromote criteria for dewiki and looked at the autopromotions since it started up again.

It seems there are multiple weird things going on with autopromotion now:

  • Blocked users are autopromoted. That wasn't the case when it was still working (see our docs). This is particularly problematic as we have used 0-second blocks before to prevent auto-promotion for certain users. I looked at the config after the patch and though the comment seems to be misleading neverBlocked seems to be correctly set to the same value as before (true). Not sure what is going on there.
  • Administrators and editors suddenly get auto"promoted" to have autoreview right as well.
  • At least one user got the autoreview right even though they don't seem to be eligible, see check with my tool, promotion.
Udo_T added a comment.Tue, Sep 15, 9:50 AM

In dewiktionary, the user "Wegner8" also automatically became "autoreview", although he had already been blocked, see blocklog and user rights log

And yesterday the user "Pametzma" became "autoreview", although he is already an "editor" since october 2012 (see user rights log). This behavior didn't exist in the past, but if that were the only side effect, it wouldn't be so serious in my opinion, because it would be formally correct.

But the fact that previously blocked users can now get "autoreview" automatically is really not good...

  • Administrators and editors suddenly get auto"promoted" to have autoreview right as well.

And yesterday the user "Pametzma" became "autoreview", although he is already an "editor" since october 2012 (see user rights log). This behavior didn't exist in the past, but if that were the only side effect, it wouldn't be so serious in my opinion, because it would be formally correct.

I don't think this has changed, it has always been this way. The "autoreview" and "editor" (and "sysop") groups are separate, even if they all share the user right to mark your own changes as reviewed, and the software will add you to the "autoreview" group whenever you meet the criteria, even if that doesn't give you any new rights.

I looked at de.wiktionary only, and in the older logs, there are a few more instances of this happening: https://de.wiktionary.org/w/index.php?title=Spezial:Logbuch&offset=&limit=500&type=rights&subtype=autopromote search for "von Sichter zu Sichter und Passiver Sichter", it happened 53 times between 2013 and 2015. It would presumably only happen if the user was added to the "editor" group manually before it would happen automatically, and you probably started doing that less often after 2015?

Similarly on de.wikipedia: https://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&offset=&limit=500&type=rights&subtype=autopromote there are 5 cases in 2019 (before this bug happened).


I'll look at the other weird things you reported and try to figure out why they happened.

@Count_Count @Udo_T Do you have some easy way to check the same for users who were promoted in the past? I'm trying to figure out if I broke something in the configuration I changed, or if something was broken in the code between 2019 and now, or if this issue was already there before 2019 but no one has looked at the autopromotions as carefully as we're looking now. (And depending on this, I'm also trying to figure out if the configuration changes I made should be reverted to disable autopromotion entirely again.)

  • Blocked users are autopromoted. That wasn't the case when it was still working (see our docs). This is particularly problematic as we have used 0-second blocks before to prevent auto-promotion for certain users. I looked at the config after the patch and though the comment seems to be misleading neverBlocked seems to be correctly set to the same value as before (true). Not sure what is going on there.

In dewiktionary, the user "Wegner8" also automatically became "autoreview", although he had already been blocked, see blocklog and user rights log

But the fact that previously blocked users can now get "autoreview" automatically is really not good...

It looks like checking the 'neverBlocked' option doesn't work, and this seems to be a new bug.

I wrote a script trying to see if any of the previously promoted users have been blocked at the time. I haven't found any, but instead confirmed that all of the recently promoted users have been blocked before!

(some of the blocks are from 2007… maybe those folks deserve a second chance if they're still active after 13 years, heh)

I filed a separate task about this: T262970

Let's take a closer look at this one.

For reference, the dewiki config for "autoreview" ("Passive Sichter" / "Passive Sichterin") from https://noc.wikimedia.org/conf/highlight.php?file=flaggedrevs.php:

	$wmfStandardAutoPromote = [
		'days'                  => 60, # days since registration
		'edits'                 => 250, # total edit count
		'excludeLastDays'       => 1, # exclude the last X days of edits from below edit counts
		'benchmarks'            => 15, # number of "spread out" edits
		'spacing'               => 3, # number of days between these edits (the "spread")
		'totalContentEdits'     => 300, # edits to pages in $wgContentNamespaces
		'totalCheckedEdits'     => 200, # edits before the stable version of pages
		'uniqueContentPages'    => 14, # unique pages in $wgContentNamespaces edited
		'editComments'          => 50, # number of manual edit summaries used
		'userpageBytes'         => 0, # size of userpage (use 0 to not require a userpage)
		'neverBlocked'          => true, # username was never blocked before?
		'maxRevertedEditRatio'  => 0.03, # max fraction of edits reverted via "rollback"/"undo"
	];
...
		$wgFlaggedRevsAutopromote = $wmfStandardAutoPromote;
		$wgFlaggedRevsAutopromote['edits'] = 300;
		$wgFlaggedRevsAutopromote['recentContentEdits'] = 5;
		$wgFlaggedRevsAutopromote['editComments'] = 30;

Your tool outputs the following failures: (please excuse my machine translation)

The user has already been blocked.

Yeah, this is broken, see my previous comment for details.

With 92 edits in the article namespace, the user account has fewer than the required 150 and with 6 viewed edits fewer than the required 50.

Looks correct… however, as noted elsewhere in the configuration: "Either totalContentEdits reqs OR totalCheckedEdits requirements needed".

I guess the totalCheckedEdits requirement must be fulfilled then (although I didn't check it, I'm not sure how exactly this requirement works – your tool also doesn't seem to check that?)

With 4 edits, which are at least 3 days apart, the user account has fewer than the required 7.

I don't really understand these requirements either, but looking at the user's contributions, this looks like it would be fulfilled too?

Count_Count added a comment.EditedTue, Sep 15, 9:01 PM

Thanks for looking into this.

With 92 edits in the article namespace, the user account has fewer than the required 150 and with 6 viewed edits fewer than the required 50.

Looks correct… however, as noted elsewhere in the configuration: "Either totalContentEdits reqs OR totalCheckedEdits requirements needed".
I guess the totalCheckedEdits requirement must be fulfilled then (although I didn't check it, I'm not sure how exactly this requirement works – your tool also doesn't seem to check that?)

The translation "6 viewed edits" should be "6 checked edits". So the tool does check that and there were only 6 instead of the required 50. This corresponds to the edits marked blue in the list of contributions (last 24 hours are not counted by either the tool nor the autopromote code). The user has many more today not yet counted (made after they got the autoreview right).

With 4 edits, which are at least 3 days apart, the user account has fewer than the required 7.

That seems broken in my tool, will double-check.

matmarex added a comment.EditedTue, Sep 15, 9:50 PM

Thanks for looking into this.

With 92 edits in the article namespace, the user account has fewer than the required 150 and with 6 viewed edits fewer than the required 50.

Looks correct… however, as noted elsewhere in the configuration: "Either totalContentEdits reqs OR totalCheckedEdits requirements needed".
I guess the totalCheckedEdits requirement must be fulfilled then (although I didn't check it, I'm not sure how exactly this requirement works – your tool also doesn't seem to check that?)

The translation "6 viewed edits" should be "6 checked edits". So the tool does check that and there were only 6 instead of the required 50. This corresponds to the edits marked blue in the list of contributions (last 24 hours are not counted by either the tool nor the autopromote code). The user has many more today not yet counted (made after they got the autoreview right).

Oh, my bad, I misread that completely.

I looked at the code handling 'totalCheckedEdits' now, in the method reviewedEditsCheck(): https://github.com/wikimedia/mediawiki-extensions-FlaggedRevs/blob/39a979cb35945ac9e778cd56899d98d7ae947641/backend/FlaggedRevsHooks.php#L977

It's an absolute pain to decipher this because of the ongoing 'actor' table migration, which means that there are several tables this could end up querying, depending on the migration stage; and also because the code has some optimizations to avoid scanning more edits than necessary.

But as far as I can tell, it ends up running a query like this:

select count(*)
from revision
left join revision_actor_temp on revactor_rev=rev_id
left join actor on revactor_actor=actor_id
left join user on actor_user=user_id
left join flaggedpages on fp_page_id=rev_page
where user_name='IntelTesla'
and rev_timestamp < '20200914214500'
and ( fp_pending_since IS NULL OR fp_pending_since > rev_timestamp )

…which is returning 549 for me at the moment.

It looks like it doesn't really count the number of checked edits – it counts the number of edits that are not waiting to be checked (in other words, edits not listed on Special:PendingChanges or Special:UnreviewedPages?). This includes edits in namespaces where FlaggedRevs is not enabled, edits that have been reverted, etc.

So I think this works correctly (or at least, in the same way it has worked previously for years, not necessarily how it was documented to work…).

The issue with blocked users being promoted (T262970) should be resolved now.

Only users on de.wikipedia, de.wiktionary and pl.wikipedia were erroneously promoted. I wrote a message on pl.wp asking administrators to review the autopromotions: https://pl.wikipedia.org/wiki/Wikipedia:Prośby_do_administratorów#Nieprawidłowo_automatycznie_nadane_uprawnienia_redaktora. I would appreciate if someone could do the same on de.wp and de.wikt.

Sorry about that. It was an unrelated bug in the code, introduced in some refactoring in September 2019, and it went unnoticed because autopromotion was broken in general because of this bug.

For reference, this is the script I'm using to track new autopromotions since this bug was fixed, and its current output:

de.wikipedia.org74log
de.wiktionary.org3log
pl.wikipedia.org3log
DannyS712 added a comment.EditedWed, Sep 16, 12:17 AM

@matmarex the rights should probably also be removed from the users with blocks, since they were autopromoted due to a bug. Perhaps remove them as a developer/sysadmin action?

It looks like it doesn't really count the number of checked edits – it counts the number of edits that are not waiting to be checked (in other words, edits not listed on Special:PendingChanges or Special:UnreviewedPages?). This includes edits in namespaces where FlaggedRevs is not enabled, edits that have been reverted, etc.

So I think this works correctly (or at least, in the same way it has worked previously for years, not necessarily how it was documented to work…).

It is quite possible that this is the way it worked before. But I highly doubt that it was the intended behavior as it does not match the description in the config files nor the one in German Wikipedia. Also this value is typically lower than the required number of content edits, so with the current behavior in dewiki a user needs just 50 talk page edits in contrast to 150 content space edits in order to fulfill this criteria for autoreview promotion.

1234qwer1234qwer4 added a comment.EditedWed, Sep 16, 11:22 AM

@matmarex the rights should probably also be removed from the users with blocks, since they were autopromoted due to a bug.

I guess the local admins will decide:

Only users on de.wikipedia, de.wiktionary and pl.wikipedia were erroneously promoted. I wrote a message on pl.wp asking administrators to review the autopromotions: https://pl.wikipedia.org/wiki/Wikipedia:Prośby_do_administratorów#Nieprawidłowo_automatycznie_nadane_uprawnienia_redaktora. I would appreciate if someone could do the same on de.wp and de.wikt.

will do that on the German projects later

In de.wikt, it has only occurred to one user so far and I've already taken care of that.

Best regards and thank you for making sure that "autopromote" will work again
Udo T.

@matmarex the rights should probably also be removed from the users with blocks, since they were autopromoted due to a bug. Perhaps remove them as a developer/sysadmin action?

I could do that, but:

  • Since adding/removing user rights generates notifications, I think it would be better if an admin from the local community would do it, since they'd be able to answer any questions the autopromoted users might have. It seems like a poor experience to have your user rights taken away by someone who doesn't even speak German.
  • In the past there have been, to put it mildly, disagreements about governance between German Wikipedia and Wikimedia Foundation, and I'm working for the Foundation (although this task isn't really part of my job). I don't want to cause any trouble, so I'm not going to touch anything on-wiki unless someone from the German community clearly requests it from me.

@matmarex the rights should probably also be removed from the users with blocks, since they were autopromoted due to a bug. Perhaps remove them as a developer/sysadmin action?

I could do that, but:

  • Since adding/removing user rights generates notifications, I think it would be better if an admin from the local community would do it, since they'd be able to answer any questions the autopromoted users might have. It seems like a poor experience to have your user rights taken away by someone who doesn't even speak German.
  • In the past there have been, to put it mildly, disagreements about governance between German Wikipedia and Wikimedia Foundation, and I'm working for the Foundation (although this task isn't really part of my job). I don't want to cause any trouble, so I'm not going to touch anything on-wiki unless someone from the German community clearly requests it from me.

@matmarex I think that this is not needed, local admins have already looked at this cases, see https://de.wikipedia.org/wiki/Wikipedia:Administratoren/Notizen#Sichterrechtevergabe_an_gesperrte_Benutzer

@matmarex I think that this is not needed, local admins have already looked at this cases, see https://de.wikipedia.org/wiki/Wikipedia:Administratoren/Notizen#Sichterrechtevergabe_an_gesperrte_Benutzer

Thank you for the note, and thanks to @Count_Count who started that discussion!

I'll keep this task open for a few days while I watch the autopromote logs on the wikis, but I'm hoping that everything is resolved now.

matmarex closed this task as Resolved.Fri, Sep 18, 10:24 PM

I think everything is working correctly now. There has now been a decent number of promotions on multiple wikis.

de.wikipedia.org217log
de.wiktionary.org4log
en.wikibooks.org6log
he.wikisource.org1log
pl.wikipedia.org9log
ru.wikisource.org6log
sq.wikipedia.org7log

(and most importantly, the promotions of blocked users stopped. I'm really sorry about that, it shouldn't have taken us three tries to fix that bug)

Big thanks to @Count_Count and also @Udo_T and @1234qwer1234qwer4 for checking the autopromote logs, verifying the correctness and spotting the problem with blocked users (repeatedly), for @Wargo for proposing the solution for the config problem, and for @DannyS712 for fixing the bug with blocked users getting promoted.