@Zache are you able to describe what you are referring to above in a bit more detail? I want to make sure I'm understanding what you are saying before responding.

In T265896#6560903, @Lucas_Werkmeister_WMDE wrote:

I don’t understand what this task is asking for. The proper way to access the Commons query service from the Wikidata query service would be through SPARQL federation, not MWAPI – as you certainly know, since you created T265891: Add Wikimedia Commons Query Service endpoint in the WDQS federation whitelist just before this task. The only reason I can think of to use MWAPI is because commons.wikimedia.org is already on the WDQS MWAPI allowlist…

! In T265291#6557038, @ppelberg wrote:
With the above said, we'd like to experiment with the Reply Tool not outputting any content/syntax that people did not explicitly type themselves to start.

It seems that we could do spacing with nowiki also instead of html-comments. With nowiki broken comments would not fail silently.

In the enwiki's help page, the spacing between items should be done using comments. Like this in wikicode.

@ppelberg It was to make editing the wikicode easier. The original proposal was in the village pump discussion "Selkeyttävä ehdotus in 2005. It was low volume and contained only three comments. The next village pump discussion which referred to empty lines in discussions was in 2015 (Muistutus_keskustelusivukäytännöstä) when Otrfan notified that writers should follow the new line guideline to make commenting more easier.

Thanks. It however should be able to handle cases like this too (in wikicode) where comment is splitted to multiple dd:s.

At HTML-level it looks like this. So, with newlines, the extra margin between rendered comments comes from the margin between separate lists. However, as Whatamidoing (WMF) noted in village pump the separated lists are an accessibility problem for screenreaders etc.

Hmm, it seems to be working now though I tested the url before I submitted the bug report. If it stays up then this can ticket can be closed.

In Wikimedia Commons is language selector of old wgExtraLanguageNames languages is now broken. Those languages cant be selected from the user interface. If I understand code correctly currently those languages are defined in wbTermsLanguages.json for CaptionsPanel.js.

@Marostegui can you check if problem exists in the production db too or just that we cant see those users in labs database because of sanitization?

Investigated little bit. I suspect that there has not been any edits for those users, but i cant confirm this edits could be deleted with oversight too. However, user_id 310454 was referenced from abuser_filter_log table and second user_id 318872 from logging table.

T262196 seems to be related to same root cause too.

Thank you!

Confirming, the map seems to work, thank you for everybody involved!

So it would be just to add wikilovesmonuments.org to config files regexp?

Thanks, here is some screenshots from my computer.

@AntiCompositeNumber @Aklapper This seems to trivial to fix as it is just configuration change in maps.wikimedia.org, however I don't know who to ask. Do you have any ideas who to ping?

hmm, oauth works for with maps.wikilovesmonuments.org but not in monumental.toolforge.org

I think that the reason is that there is still old callback url, but site itself is moved to monumental.toolforge.org and login security doesn't survive from redirection.

I can confirm the error

Quickfix could be to use https://monumental.toolforge.org which seems to be whitelisted. This doesn't work for all of the use cases (ie. main site is still broken)

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