| Count_Count | |
| Nov 3 2019, 12:44 PM |
| F32352010: T237191.rb | |
| Sep 15 2020, 11:30 PM |
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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| flaggedrevs: Move setting of wgFlaggedRevsAutopromote and wgFlaggedRevsAutoconfirm out of wgExtensionFunctions | operations/mediawiki-config | master | +183 -152 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T225144 Flagged Revs configuration may be broken | |||
| Resolved | matmarex | T237191 FlaggedRevs: Automatic user promotion stopped working on some wikis on June 24, 2019 | |||
| Resolved | DannyS712 | T262970 FlaggedRevs doesn't check the 'neverBlocked' / APCOND_FR_NEVERBLOCKED option when autopromoting |
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?
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.
Too bad. Only demotion of existing autoconfirmed accounts/restoring autoconfirmed starus are allowed, it seems.
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
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.
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?
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.
@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
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;
}
}
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
If you want propose patch(es), that’d be appreciated. I can look later tonight/tomorrow
@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?
Sorry, it had wrong quarry id. https://quarry.wmflabs.org/query/42368 is correct one.
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.
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.
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
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):
If not, what is the difference with other extensions?
Folks from Polish Wikipedia asked me to have a look at this…
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
Change 627332 merged by jenkins-bot:
[operations/mediawiki-config@master] flaggedrevs: Move setting of wgFlaggedRevsAutopromote and wgFlaggedRevsAutoconfirm out of wgExtensionFunctions
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.
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 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:
@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.
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:
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...
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.)
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?
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.
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.
@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 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.
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.
I could do that, but:
@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
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.
I think everything is working correctly now. There has now been a decent number of promotions on multiple wikis.
| de.wikipedia.org | 217 | log |
| de.wiktionary.org | 4 | log |
| en.wikibooks.org | 6 | log |
| he.wikisource.org | 1 | log |
| pl.wikipedia.org | 9 | log |
| ru.wikisource.org | 6 | log |
| sq.wikipedia.org | 7 | log |
(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.