Issues about specific AbuseFilter should be raised at local wiki unless it is related to the extension itself, such as a missing or broken feature.

@Bugreporter Just look at the log entries – these three rules/filters have been triggered because something is screwed up "below", perhaps AbuseFilter extension itself. It's not a problem with the rules, they have been working for years and have not been changed recently.

The first thing that comes to mind is that whoever is firing the EditFilterMergedContent hook is passing SlotRecord::MAIN instead of the actual slot being edited. I'll try to reproduce this locally and see if that's indeed the reason.

Based on my local testing, my guess was right. This was caused by r747596 -- notice how $slotRole is not passed to onEditFilterMergedContent. OTOH, it's really not that patch's fault, since the parameter is not officially documented in the hook documentation, nor is it present in the EditFilterMergedContentHook interface (see T288885).

At this point, I think that the core hook should be changed to pass this parameter. Making it mandatory would be a breaking change and we'd better replace the hook with a new one, so perhaps we can just add it as an optional (but recommended) parameter for now.

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=91.120.252.226 .

For the record, I had already created https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/776286, which is still waiting for review.
I don't think it will solve this problem. Looking at T288885, or doing something like T304238 is still much needed.

In T298672#8799137, @Jeff_G wrote:

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=91.120.252.226 .

These don't look to me like changes related to structured data.

See also the edits logged at https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=2605%3ABA00%3A4138%3A445%3A1974%3ACACD%3AE09D%3AA640&offset=&limit=50 and https://commons.wikimedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=Haansn08 .

In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=804669319 Cessy3 vandalistically added en caption "welcome". In edit https://commons.wikimedia.org/w/index.php?title=File:Queen_Victoria_by_Bassano.jpg&diff=prev&oldid=841293383 Haansn08 removed that caption, but earned abuse filter log entries https://commons.wikimedia.org/wiki/Special:AbuseLog/10343284 and https://commons.wikimedia.org/wiki/Special:AbuseLog/10343285 in the process because "New page wikitext, after the edit ($1) (new_wikitext)" is completely wrong (it is not wikitext at all, but a bastardized text representation of the change in wikibase-mediainfo) and triggered Commons Abuse Filter 58. Perhaps we can exclude changes where "New content model ($1) (new_content_model)" is 'wikibase-mediainfo' to remove such false positives?

I ran into this at https://commons.wikimedia.org/wiki/Special:AbuseLog/10870632, when undoing a change to structured data on https://commons.wikimedia.org/wiki/File:Rudolph_the_Red-Nosed_Reindeer_defective_copyright_notice.jpg (this happened both when undoing both changes to the page text and the structured data in one edit (using the undo link on https://commons.wikimedia.org/w/index.php?title=File%3ARudolph_the_Red-Nosed_Reindeer_defective_copyright_notice.jpg&diff=918049009&oldid=719815915) and when undoing the structured data only. What I see is that old_wikitext is the page text followed by the structured data, while new_wikitext is my changed structured data followed by the original structured data. Note that I was signed in at the time, which does seem to be different from the original report.

@Pokechu22: Commons Filter 303 operates on both anonymous and new users.

Hi! I have just stumbled upon this ticket. I have been contributing on Commons for the past ~10 years, though a bit more actively in the last 4 or so.

I'm just chiming in to mention that I've just hit this roadblock and @Jeff_G kindly shared the link to this ticket.

It seems like there is no automatic way for being allowed to revert SDCs (say, like the "extendedconfirmed" group on en.wiki)

I do think this might be a barrier to some contributors of SDC in activities we are planning in the Biodiversity Heritage Library Wiki Working group.

I'll add @GFontenelle_WMF to this ticket, as she might be interested in this too.

To illustrate, here is a screenshot of what happens when an anonymous user tries to undo the last SDC batch added to

https://commons.wikimedia.org/wiki/File:Historia_naturalis_Brasiliae_(Page_99)_BHL289062.jpg

Ran into this problem too while reverting vandalism in the Captions field on a file.

abuse filter log

If the file is attached to Wikidata, then it will include the added lines (that AbuseFilter think added) below:

http://www.wikidata.org/entity and whatever (see my linked abuse filter log as example)

So could that be excluded from the filter, as a temporary workaround, to prevent false positives?
Note this would not work if file is not attached to Wikidata.