In T72245#741801, @Aklapper wrote:

I would still prefer to "make everyone suffer" to having broken links in email clients which don't interpret bytes correctly.

You wrote this 9 years ago. Perhaps now such clients, if they still exist, are outdated and marginal enough that we can ignore them?

FYI: this is a proxy blocking bot, doing > 4 000 000 blocks per year in last 6-7 years. So, it's log contains 25-30 mln. records or even more.

...but attacks on OSM are still going, bots running every night, many labels was vandalised on OSM last evening by ruwiki users reports.

Looks like wiki maps are fixed now, I can't find this kind of vandalism on them.

It's on entire map of Russia...

Thank you, I successfully started webservice.

@Aklapper please, merge this task with T243119 (I can't find how to do it myself)

@Beetstra The reasons why we requested this change is

1. because archiving bots can't archive discussion, if it contains a link, blacklisted after discussion. Ruwiki lost thousands of discussions because of it, it is one of the most disruptive events in Wikipedia history.
2. because bots like AWB repairs broken link syntax on pages when edit in automatic mode, and if bot repairs spam link, it can't save edit.

In T313107#8926258, @Beetstra wrote:

if a vandalism edit removes the blacklisted link, and then a good follow up edit makes it impossible to revert the vandalism edit you cannot edit the vandalised information back in because you are not a bot.

Ruwiki community has decided to create a new protection level for autoreviewers, not to create an extendedconfirmed group. stjn's proposals here are some kind of POV-pushing to try to create an extendedconfirmed group in ruwiki in the future, no need to condone these attempts.

@Nux can https://www.mediawiki.org/wiki/Template:Graph:PageViews be replaced with the Timeline on something other? It is very high use case in ruwiki, pageviews graphs on talk pages.

@Legoktm I don't know why T313107 isn't done, so if you can execute T313107 - please, do it.

When Graph will be enabled on main wikis?

@MarcoAurelio Spamlist prevents archiving of discussions containing links that were spammed after they were posted in the discussion, and countless threads in ruwiki were lost, not archived due to the spamlist. The spamlist also interferes with editing in AWB, because a couple of years ago the spamlist began to trigger to spammed links in the edit description, and AWB adds a piece of text that was edited to the edit description. Disabling the spam list for bots is the first and obvious task after this technical right was finally created.

@Superpes15 , discussion ended and has a summary, https://ru.wikipedia.org/wiki/Википедия:Форум/Общий#Право_игнорировать_спамлист_для_ботов

This problem was discussed infinite amount of times, but OK, I will start a discussion, result will be in several days.

@Nikki is there a right way to use correct, not outdated language codes, by using not that script, but internal Wikidata mechanics?

It doesn't happen in the last years.

In T313107#8196706, @Novem_Linguae wrote:

Should code be added to SpamBlacklist to automatically add sboverride to all bot groups by default? Or do we need to do this one wiki at a time via config files?

+1.

• What kind of configuration or setup do web services require? Does the mono app run a web server by itself, or is an external web server such as apache2, nginx or lighttpd required?

I'm using a lighttpd web server (default web server on Toolforge). A file .lighttpd.conf contains this strings:

@Tgr Please, explain me:

1. Why this request should entail "breaking MediaWiki's permission management"?
2. Why "edit" link are showing when you are seeing diff using blocked IP, and "thank" link doesn't showed. What's the difference?
3. Why you say "it wouldn't make those users' lives much easier", if you don't experience this problem, and a user who experience this problem says you it will make his life easier?

Ping @kaldari @wctaiwan (people say me this users is a Thanks extension developers)

I compiled last mono version in my Toolforge directory and, when I use it, this error doesn't occur.

Yeah, now such request executed in 34.38 seconds.

It works, fixed.

Go to https://ru.wikipedia.org/wiki/Special:UnreviewedPages , review any page.

And... why, and when it will be merged?

@Ladsgroup could you answer my last question? https://phabricator.wikimedia.org/T277883#7642320

Was this change https://phabricator.wikimedia.org/T277883#7363935 merged? There is an option about I write here https://phabricator.wikimedia.org/T277883#7363544 , looks like this change was to remove this option, but it still exist in ruwiki: https://ru.wikipedia.org/wiki/Special:Stabilization/Deus_Ex (second options block)

I assume this feature could be safely removed due to its uselessness for almost anyone.

I think about a simple mechanism without any encryption and keys: create a tool on Toolforge, authorise users with OAuth, write votes into plaintext file and set permissions of this file to rw-------. Tool owner (it can be crat or CU) can see this file and publish results after voting end.

@Ladsgroup thanks. So maybe a filter by autoreviewing can be removed from the site interface?

Martin helps me.

@Urbanecm you are an admin and bureaucrat on betavotewiki - so, please, can you create an account for me and grant me rights for creating elections?

@Huji I don't see this wiki in drop-down list of wikis on https://test.wikipedia.org/wiki/Special:SecurePoll/create

@Huji I can't start this testing for testwiki (and ruwiki and votewiki), I wrote T295214 because of this.

Looks like it works, thanks.

I'll waiting when automatic events will be cleaned up completely and I can remove records about they from local documentation: https://ru.wikipedia.org/wiki/Project:Патрулирование#Обозначения_действий_патрулирования_в_API

1. Go to link https://ru.wikipedia.org/w/index.php?title=Project:К_посредничеству/Украина/Запросы&offset=20180908134724|94961911&limit=500&action=history
2. Press "500 newer"

@Ladsgroup will this be continued?

Special:UnreviewedPages is a list of unreviewed pages (pages has no reviewed versions at this time).
Special:PendingChanges is a list of pages, that has old reviewed version, but its last version is unreviewed.
It's totally different lists, unreviewed and outdated reviewed pages.

@Ladsgroup why you think UnreviewedPages is needless special page?

There is an option in stabilization interface, "Restrict reviewing this page only to sysops", see https://ru.wikipedia.org/wiki/Special:Stabilization/Deus_Ex . We considered in ruwiki that this option is useless and every time, when someone turns it on (very rare), he did it accidentally and this option turns off every time when any user draws attention to this.

I can't even add a page ( https://ru.wikipedia.org/wiki/Воук_%28политика%29 ) to my watchlist. Error 503 or "server doesn't responding".

FYI: ruwikinews "owners" (Krassotkin & Co.) recently uploaded to ruwikinews millions of "news", created 10-15 years ago on other Russian-language news websites, owners of which published this content under free license. I call on Wikimedia administrators to delete this mass upload, because this isn't sort of content for which Wikinews was created.

I mean, I thought this patch will remove some lines, not add them :)

I thought user group "reviewer" was defined somewhere in configuration file and can be removed by deletion of this definition. But you know FlaggedRevs much better than me, so do what you see fit.

https://ru.wikipedia.org/w/index.php?title=Special:Log&type=review&subtype=autoaccept
Looks like this isn't done yet, autoreview logs still exists from year 2008 and new autoreviews from July 4 added just now.

OK, I thought it's very easy, just removing the usergroup definiton from the config file, less than 1 minute of work.

@Ladsgroup when this process will be continued?

An example from first post on this task doesn't work now because Flow was fully disabnled in ruwiki, but I assume the problem still exists in engine.

The pending changes notification, displayed above articles with pending changes, displays the same text twice, see

@Bstorm https://quarry.wmflabs.org/query/23027 , plus my ORES-using-vand-rollbacking bot stuck and rolls back only registered users last 1.5 days again.

@Bstorm we have this problem again, request SELECT * FROM actor WHERE actor_user IS NULL returns no data.

If you set this checkbox, users who browse "Pages for reviewing" special page, will see "Some user reviewing this page" notification on the string with this pagename.

It's a good idea. There was a project in ruwiki to use 2-3 tiers to extended quality check, this was tested during several years, but ended because everyone stopped doing this unhelpful activity. Recently a discussion was held in ruwiki, as a result of which it was decided to not use 2-3 tiers.

In T21322#231952, @Legoktm wrote:

I'm not sure if this is even possible, since the "bot flag" is a temporary thing, only stored in the recentchanges table, and not in the logging table.

Yesterday an IP user vandalised a page in ruwiki, see [1]. We can see this edit in the "recentchanges" table of Toolforge DB replica: https://quarry.wmflabs.org/query/23027 . Edit with rc_actor=12321013 is vandal edit, edit with rc_actor=4546 is my rollback. You see 2 records for any edit because one of them contains ores=damaging value and another contains ores=goodfaith value.

Will any action be taken on this request?

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

4 admins of 80 in ruwiki deliberately refused review right, because review interface interferes with them. I think this change shouldn't be released, the system works with current settings more than 10 years and suits everyone.

See also T229596