fixed by Para. Thank you.

If communities want to continue to use where they should contact to get some of the teams to be responsible? (afaik this is the current situation as there is no replacement and the communities like it as a tool)

So,. if I understand correctly the problem is that the views used currently in the tool labs are fucked by design and because that everything is unusable slow?

pushing this little bit up. It would be nice to get goodfaith working.

In T246720#5938796, @Wickie37 wrote:

Looks like I was right with the faulty 'fp_stable' in the 'flaggedpages' db table:

Yes, the sql fiwiki_p connects to fiwiki.analytics.db.svc.eqiad.wmflabs .

Bug: Try to edit a specific page on deWP throws InvalidArgumentException T246720

One clear use case for Wikimedia editors who aren't coder but who can write/modify SPARQL queries is to sort and filter Petscan and Listeria results.

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

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

In T237191#5910169, @Brainswiffer wrote:

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

In T237191#5909711, @Brainswiffer wrote:

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

In T234743#5896089, @JEumerus wrote:

I believe what Doug Weller is trying to say is that enwiki oversighters are all admins and admins on enwiki hold the "review" permission.

Any hope that this would go forward?

Masumrezarock100 wrote:

In T234743#5843628, @Xaosflux wrote:

Note on the screen shot from Cyphoidbomb's failure above, this is referencing a group that doesn't even exist on enwiki "Editors".

A bug like this isn't so surprising since FlaggedRevs is buggy and has no maintainer currently But not sure why it is affecting Translate extension.

The second option could be to set wgFlaggedRevsHandleIncludes to FR_INCLUDES_CURRENT ( value = 0 ) in InitialiseSettings.php so that FlaggedRevs would not track the included pages. However, this would mean that there would not be notifications from the file, module or template changes in articles either. If you doesn't need those notifications then this would simplify the user interface and this would be my recommendation.

Probably related to edits made on MediaWiki-extensions-FlaggedRevs (MediaWiki 1.35/wmf.10)

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

I think that this is because page uses the talk page in a way that it is included as a template. (ie. there is a link in templatelinks database table between page and the talk page) the edits of the talk page will be handled like the edits to templates used in the article.

Based on Manual:$wgExtensionFunctions: This variable is an array that stores functions to be called after most of MediaWiki initialization is complete. Note however that at this point the RequestContext is not yet fully set up, so attempting to use it (or equivalent globals such as $wgUser or $wgTitle) is liable to fail in odd ways. If you need to use the RequestContext, consider the BeforeInitialize and ApiBeforeMain hooks instead.

Tested that flaggedrevs_promote is still updated

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

In T237191#5741228, @Masumrezarock100 wrote:

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

This can be also reproduced in Finnish Wikipedia. (it reproduces always, but minimal ui will make it more visible in fiwiki)

One thing to check would how the change affected the review workload and review backlog. Ie was there effect on the number of reviewers and how reviews per the reviewer are distributed between users.

Autopromote is broken for FlaggedRevs, so it is one high priority bug more. T237191

just note for myself. Wikimedia commons requires also local mediawiki:lang/langcode pages for https://commons.wikimedia.org/wiki/Module:Languages

Wikimedia Commons requires also local mediawiki:lang/langcode pages for https://commons.wikimedia.org/wiki/Module:Languages

@Reedy The date June 24, 2019 matches with your FlaggedRevs config rework but i didn't spot yet anything which would have broken the autopromote.

There is flagged revs bug T150600 related to global bot flags and also new bug T233561 related to permission randomly fails.

@Aklapper It is definitely something which is worked on so tagged WMFI to it.

In T233561#5570753, @MBH wrote:

@DannyS712 @Tgr @Zache I wrote a bot that reviews all edit sequences that was not reviewed due to this bug. I wrote it for ruwiki, but if you want, I can launch it for your wikis too, if your wikis grant "editor" flag to my bot.

Would it help for debugging if we could replicate this in test2.wikipedia.org?

AFAIK all Flaproblems what i have seen can be explained with settings from wmf-config/flaggedrevs.php is not loaded.

In T233561#5537057, @Tgr wrote:

I see all the groups I should be seeing (["checkuser", "sysop", "*", "user", "autoconfirmed"]).

The error message says The action you have requested is limited to users in one of the groups: Editors, Reviewers.
What it should say (and does if I load the page in incognito mode) is Administrators, Editors. So this does seem like an issue with site configuration being messed up occasionally.

I tried to check yesterday if the patrolling is working or not too, but there are not many wikis where wgUseRCPatrol and FlaggedRews are both enabled. Also when revision is manually reviewed then it will be patrolled too which will mask the problem.

In T233561#5537071, @Neolexx wrote:

To the best of my knowledge en-wiki doesn't use FlaggedRevs extension (as a replacement for the native patrol mechanics). Compare

I made a small script for myself to see if the UI (javascript) code thinks that I am autoreviewed or not. Script colorifies the usarname on the top of the page and prints a list of the groups on the end of the page.

@Reedy do you have any educated guess what is going on here?

Confirmed in fiwiki too (user Aulis Eskola is in 'editor' user group which have autoreview user right and his edit should have been automatically reviewed)

• https://fi.wikipedia.org/wiki/Special:Log?type=review&user=&page=Painokytkin&wpdate=&tagfilter=&uselang=en
• https://fi.wikipedia.org/wiki/special:Userrights/Aulis_Eskola?uselang=en
• https://fi.wikipedia.org/wiki/special:Listgrouprights?uselang=en

Based on huwiki configuration I think special:unreviewedpages is allowed only for Administrators and Editors. Users with only autoreview right should see a permission denied error on Special:UnreviewedPages.

pushing this little bit up. It would be nice to get goodfaith working.

In T209224#5496088, @Halfak wrote:

... We should instead look at the number of edits that need to be reviewed in order to catch most of the vandalism. Without something like ORES in place, this is really just a factor of the total number of edits. ...

I would amend the patch and edit the task description to include removing the redundant nys.

@Reedy I think that we are happy that you are maintaining it and thank you for fixing the configuration.

Hmm, problem may be just because 'ukwiki' => false is missing from wgFlaggedRevsOverride setting in InitialiseSettings.php ?

seems to work, thanks

https have error NET::ERR_CERT_COMMON_NAME_INVALID

• https://wikipedia.fi/

Yes, we removed the local bot flag from Xqbot and its edits are not automatically reviewed.

• https://fi.wikipedia.org/w/index.php?title=Pan-American_Highway&action=history

@Samat Is there any comments from community to the results?

for sju, sjd, and rmf this will be already done in T226701.

In T226701#5304443, @Urbanecm wrote:

@Yupik Are the two changes dependent on each other in some way?

Reported again in fiwiki by three users. One commented also that mobile site was working better.

In T222309#5265020, @Cparle wrote:

Live on commons now. Ok to close the ticket @Yupik @Zache @Keegan ?

now sms is added to beta commons config it works in captions in file info page. However it still doesn't work in upload wizard (missing in both: caption and description language selector)

Also https://www.mediawiki.org/wiki/Manual:Revision_table is outdated

@Aklapper Ok one blocker removed

(@Aklapper) if this is something which needs to be asked from WMF then from who or where it needs to be asked?

@Zoranzoki21 Do NOT enable VisualEditor on those wikis. Enable on only in fi.wikibooks.org

Hmm, code should be live in Commons. sms is still missing from user interface because language is not configured to commons.

AFAIK. SDC captions are same thing than Wikibase labels. It would be good thing if supported languages for monolingual texts and terms would be same. Terms = captions, labels, descriptions, aliases.

Also related to that is there some reason why moratoira cannot be removed as RFC by @Dereckson was closed without resolution and biggest voiced reason for it in first place was that nobody actually did enabling?

So if we do not want to use wmgExtraLanguageNames for SDC (per T222309#5156677) then it needs to be fixed in code too?

Let's check if I have understood the system correctly @Nikerabbit