Analizzando i tool già presenti abbiamo Xtools che permette di estrarre una determinata categoria di edit automatici:

• https://xtools.wmcloud.org/api/user/automated_editcount/{project}/{username}/{namespace}/{start}/{end}/{tools} (Doc)

Settando il parametro {tools} su true restituisce il numero di edit raggruppati per i tool presenti qui, quindi facilmente aggregabili in base alle nostre esigenze.
La lista global include i principali tool automatici (lista parziale non esaustiva):

• AutoWikiBrowser
• JWB
• PAWS
• WPCleaner

Occorre individuare gli altri eventuali tool non conteggiati (in attesa di feedback dalla comunità).

L'etichetta porta benefici di verifica postuma degli edit. Sarei per il supporto locale essendo un tool il cui sviluppatore è quasi inattivo (vedi per esempio questo).

It works fine. Thank you!

You got a new talk message! https://it.wikipedia.org/wiki/Discussioni_utente:DLynch_(WMF)#Test

@Magnus Similar situation to T341190

In T344705#9111087, @Dreamy_Jazz wrote:

@Melos if you want this fixed now, you can define the page MediaWiki:Checkuser-cidr-tool-links with the following content:

Thank you for your fix! I think we can wait the normal deployment train (message can be easily overwritten locally).

I have seen this bug on my local installation when the core version is updated to 1.35.0-wmf.24 and vector version remains to 1.35.0-wmf.23.

Fixed in py2 to py3 migration

I've created a virtualenv with:
*pip install irc
*git clone https://github.com/sixohsix/python-irclib.git (http://python-irclib.sourceforge.net/)
*pip install MySQL-python (https://pypi.org/project/MySQL-python/)
Now bots are running (via "source venv/bin/activate"+restart script) in the virtualenv but we need to update crontab (or bash scripts) to start using it

This feature comes with https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/405015/ since 14/06/2018, see https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/Storage/PageUpdater.php$1159
and T196400

In T209585#4752268, @Huji wrote:

Melos, this patch looks good. Please post it publicly and I will +2 it. Like Brian, I think it is okay to work on this in public.

Done. https://gerrit.wikimedia.org/r/474077

Per comments in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CheckUser/+/473730/

I have updated my php version from 7.0.10 to 7.0.32 and everything works fine.

Also REL1_32 branch is affected by the same error.

In T209423#4744575, @Addshore wrote:

What version of mediawiki are you trying to install?

master version.
After a manual installation there are other errors while attempting to save like Fatal error: Cannot use MediaWiki\Revision\RevisionSlots as RevisionSlots because the name is already in use in includes\Storage\RevisionSlotsUpdate.php on line 28
I don't know if they came from https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/461714/

• In some places, such as the screenshot you included from Special:AbuleFilter, the field is treated plain text.

Correct, it is only a description so plain text is correct IMHO.

• In other places, such as Special:AbuseLog and the "preview selected message" feature when editing a filter, it's treated as wikitext and gets parsed to HTML.

Here there is the first problem, we need to change it in plain text (see for ex. T141670).

• And in some places, such as the warning produced on the edit page when the filter actually fires, it's treated as wikitext and parsed to HTML and then that HTML is treated as wikitext and parsed a second time, which breaks links in the original "wikitext" and leads to display as shown in this task's description.

What really needs to happen is that one interpretation, plain text or wikitext, needs to be chosen and used everywhere. IMO it should just be plain text. And then either way the edit page warning needs to be fixed to not double-parse.

I agree, plain text is the better choose and so we can also remove parseinline.

As I have explained in gerrit imho the patch have to check $wgBlockAllowsUTEdit. If it's set to false you don't have to show the checkbox as in Special:Block

https://gerrit.wikimedia.org/r/#/c/390074/

When 'afl_ip' => '' should we add a message to inform user that Originating IP address was dropped/too old or leave the user to see an empty "Originating IP address" in the results? In every case the try to access private data must be logged if $wgAbuseFilterLogAccessingPrivateDetails = true.

In T152934#3713824, @Huji wrote:

@Melos actually, there already exists $wgAbuseFilterLogIPMaxAge and it is used maintenance/purgeOldLogIPData.php

More importantly, CheckUser's version of this variable, called $wgCUDMaxAge is never used in the code to restrict the output of the query that is shown to the user; it is only used in the maintenance script maintenance/purgeOldData.php and also in CheckUser.hooks.php inside maybePruneIPData() where 1 out of every 50 queries is used to also prune old CU data.

So I think for AbuseFilter, we should just use the same strategy as well: keep the large purges for purgeOldLogIPData.php and not use $wgAbuseFilterLogIPMaxAge in the WHERE clause of the queries. If the user tries an old log entry, they will see a blank instead of the IP, not an error message. Maybe we can also add a separate function similar to maybePruneIPData() in AbuseFilter, but that I think is a separate task.

In short: we already have both a variable for max IP age, and a mechanism for purging it. So I won't work on any of it for this patch/task.

We could check for global $wgCUDMaxAge but if wgAbuseFilterPrivateDetailsMaxAge is setted it override $wgCUDMaxAge so site admins can have more flexibility in configuring AF.

Another point: In Wikimedia sites we could decide to view data only from a X period (for ex 3 months). Since IP are stored in afl_ip field and we can't saefly drop it from the database we should add another time variable for it to compare with afl_timestamp. Then, if filter log timestamp is older than our max time limit, user will be warning with a "too old" message.

While I'm testing the patch above I was thinking to create another configuration variable to require a valid reason. Since are private data site admins could decide to require from users a valid reason to see them. So setting a "AbuseFilterLogAccessingPrivateRequestReason": false in extension.json and checking for it in the code should be a good point.

What about to separate rights for logs and for view information as in the CU extension? This will make it more configurable.
For example. A trusted user group can be able to see only the log without any risk.

https://login.wikimedia.org/w/index.php?title=MediaWiki%3ACheckuser-userlinks&type=revision&diff=23&oldid=16

While I'm working on something that show links for CentralAuth and GlobalBlocking I've sent a patch for "checkuser-userlink" message, so we can add the equivalent of "checkuser-userlinks-ip" also for registered users. Than we can close this bug and open another one as new feature request.

I'm working on it and I'll send a patch for code review. I'll try to add new links as integration with global extensions.

I think it don't pass the part ( IP::isIPv6( $ip ) && $range < $wgCheckUserCIDRLimit['IPv6'] ) ) since 29 < 32 (range is too wide). Is the bug in the block stuffs instead?

https://gerrit.wikimedia.org/r/#/c/382979/