The code that is responsible for ensuring only one block is applied is here: https://gerrit.wikimedia.org/g/mediawiki/extensions/AbuseFilter/+/1807a077557ec1248b4ef87e46a58db3801d905b/includes/Consequences/ConsequencesExecutor.php#260.

More evidence: there is no recent connection to nowiki in Wikidata.

Idea (kind of compromise): Remove the UserGroupManager::addUserToGroup call from the database updater (SchemaChangesHandler). The user will be created when the extension is installed but will be promoted only if the wiki decides to use the aggressive counter-features.

In T351573#9700054, @smihael wrote:

I can confirm that this issue persist, even after upgrading from {{LOCALDAY}}._{{LOCALMONTHNAME}}_{{LOCALYEAR}} to {{#timel:j. F Y}}.

In my opinion, this perfectly matches https://www.mediawiki.org/wiki/Manual:Reverts#Manual_revert

MariaDB [commonswiki_p]> SELECT rev_timestamp, rev_id, rev_sha1, rev_len, (SELECT GROUP_CONCAT(ctd_name SEPARATOR ',') FROM change_tag_def JOIN change_tag ON ct_tag_id = ctd_id WHERE ct_rev_id = rev_id) AS ts_tags FROM revision WHERE rev_page = 4966748 ORDER BY rev_timestamp DESC, rev_id DESC LIMIT 10;
+----------------+-----------+---------------------------------+---------+----------------------------------------+
| rev_timestamp  | rev_id    | rev_sha1                        | rev_len | ts_tags                                |
+----------------+-----------+---------------------------------+---------+----------------------------------------+
| 20240406225557 | 866349068 | c57dpmffv1kxf8a0vx8qyl8znojhcya |    2948 | visualeditor-wikitext,mw-manual-revert | <-- manual revert
| 20240406225508 | 866348947 | ew9uvbtwpzf879gv256fwqj5i2qyw14 |    2998 | mw-reverted                            | <-- reverted
| 20240406225505 | 866348942 | agq18v28t4mfvyx5fx4favkobuydziw |    3047 | NULL                                   | <-- reverted
| 20240404153001 | 865841726 | agq18v28t4mfvyx5fx4favkobuydziw |    3047 | mw-reverted,wikieditor                 | <-- reverted
| 20240404130859 | 865809957 | c57dpmffv1kxf8a0vx8qyl8znojhcya |    2948 | NULL                                   | <-- base revision
| 20200819214235 | 441012026 | c57dpmffv1kxf8a0vx8qyl8znojhcya |    2948 | NULL                                   |
| 20171016130632 | 263110882 | h9vi1gmsznx8i3pg0m5g1kue9omav1n |     570 | NULL                                   |
| 20150322224936 | 154363418 | q2me2b6y96ng7clj6og2fmoo0tc7bpr |     562 | NULL                                   |
| 20150225202308 | 151083926 | 3m9z162p02jdo6jxof2vurtaurje9f5 |     587 | NULL                                   |
| 20100614215051 |  40497753 | k8ovsfbuo8bp962xt2i5maqqb6lrql1 |     616 | NULL                                   |
+----------------+-----------+---------------------------------+---------+----------------------------------------+

#866349068's hash matches #865809957's hash, therefore all edits between are considered reverted. #866348942 is an exception, probably because it's a null edit that by definition cannot be reverted.

What is the expected behavior?

Maybe one of these recent changes is the cause?

It appears that wd admins are not willing to issue indefinite (or even long) semi-protection even for "the most common items since many contributors in the projects are not autoconfirmed on Wikidata and will not be able to add new articles if needed".

Has the option to automatically create the user account prior to the update if it doesn't exist on Wikidata been actually considered? Is it impossible, or is it just unclear whether we want to do it?

See T355639: Move "Changetags" right only for bots and administrators by default in Wikimedia production.

I think mw.hook( 'wikipage.content' ) can help.

On average, every tenth insertion.

Ideally, you would also see type=purge entries, as those are responsible for keeping the table compact...

Does selecting "Editor type" in "Dimensions" and only filtering by "Anonymous" not satisfy that?
https://stats.wikimedia.org/#/wikidata.org/contributing/edits/normal|bar|2-year|editor_type~anonymous|monthly
And if you want "unique" editors:
https://stats.wikimedia.org/#/wikidata.org/contributing/editors/normal|line|2-year|editor_type~anonymous*user|monthly

In T173144#9607532, @Michael wrote:

Is this related to T269003?

Not observed anymore.

And apparently it's been reported once again since: T329575.

Did it.

For new properties, it is better to handle it on-wiki and delete and create it again. It doesn't require a sysadmin's ("deus ex machina") intervention.

In T355763#9484918, @wmr wrote:

Is this intended? Is this a bug? If this is intended, can you add an option to allow no conversion like mw.loadJsonData("file.json", digit_conversion=False).

srwiki has three user-defined tags: Дискусија на Викимедијиној Остави, ToDoLister, Adiutor. But the activity on Special:Log/tag is minimal (and possibly unconstructive, exactly why the change would be useful).

In T355639#9561710, @stjn wrote:

will be removed from users and bots by default in Wikimedia sites

Most wikis have no user-defined tags. Only 123 wikis should be concerned:

Using Special:AbuseFilter/tools:

Chrome on Windows 10, Monobook skin.

T299308: Add Hide translations to Special:PrefixIndex made progress.

Apparently, there was an issue with the patrol button not showing up last week: T357213. I'm not sure if it is related, but it would be a weird coincidence...

I guess T343115: On Special:PrefixIndex Properties and Lexemes are not shown with their Label resolved this.

Is there an error message or does the button just not display?
The change is in the database:

+------------+----------------+--------------+
| rc_id      | rc_timestamp   | rc_patrolled |
+------------+----------------+--------------+
| 2434470175 | 20240215162738 |            0 |
+------------+----------------+--------------+

In T356984#9549944, @Ladsgroup wrote:

@UOzurumba Hi, this was already announced in the last tech news, why announcing it again?

3 is a big no-no because the behavior wouldn't match the user's expectations. 1 and 2 are ultimately the same (there would be an exception anyway). So this is just about showing a more user-friendly error message (instead of the default).
Note that this is blocked on T57755, which is an upstream task. If we chose to hardcode something and then upstream changed, it could be problematic because users would be forced to upgrade Pywikibot version.

Occurrences across wikis: P56851 (111 filters on 40 wikis)
Query:

SELECT afa_filter, ctd_name
FROM change_tag_def, abuse_filter_action
WHERE ctd_user_defined = 1
AND afa_consequence = 'tag' AND (
  afa_parameters = ctd_name
  OR afa_parameters LIKE CONCAT('%\n', ctd_name)
  OR afa_parameters LIKE CONCAT(ctd_name, '\n%')
  OR afa_parameters LIKE CONCAT('%\n', ctd_name, '\n%')
);

Unlike BlockedExternalDomains in its current shape, SpamBlacklist checks edit summaries for spam, too (T15599#173812, code snippet: T296102#9534553).

The preferences are relevant only to those who use the old recent changes design ("Use non-JavaScript interface"). Others can configure their default directly on Special:Recentchanges/Special:Watchlist, then the preferences have no influence. (You can do much more in the views than in the preferences.)

For reference, edit summaries are indeed conditionally checked for spam:

I forgot to mention that, but it obviously does not apply here. The base revision was the eighth most recent.

What is the motivation behind the procedure?

I was suspicious there could be a race condition since my bot uses the asynchronous saving feature. So, I forced it to save synchronously. When I have it log out before running the script, I get messages like