At https://www.mediawiki.org/wiki/Topic:Vhera1g9uap2iose another user reported the same. Their example file was https://en.wikipedia.org/wiki/File:Minister%20prostrates%20at%20the%20start%20of%20United%20Methodist%20Good%20Friday%20liturgy.jpg.

I examined the logs for a few examples of mine (a few months ago), and it seems that AbuseFilter kicks in for old revisions as well, so it seems for me that the only solution is to have the OTRS tag not have been added ever, which is impossible, of course.

In T224802#5970934, @Tacsipacsi wrote:

I examined the logs for a few examples of mine (a few months ago), and it seems that AbuseFilter kicks in for old revisions as well, so it seems for me that the only solution is to have the OTRS tag not have been added ever, which is impossible, of course.

Has it been tried to have these transferrals skipped by AF/69? There seems enough content there to consider to be used. If we still wish to track we can just have a complementary template that tags, but not warns. Seems that if we have a little more certainty on the appropriate prior tagging that it seems okay to let them in unchallenged. One would think that there are going to be a very limited number of cases of someone running through a previous wiki as a means to sneak in an OTRS permission at Commons.

A note from yesterdays discussion: Bad SVGs (see T216516) and most AbuseFilters (see T223288) are about files that are potentially bad. In contrast, OTRS tickets mark files that are known to be good. Therefore it appears like we can skip this OTRS check, even for the latest file revision.

However: It seems like this check is implemented as an AbuseFilter. We can not just disable all abuse filters for older file revisions, because we would disable all critical filters as well then. It's also not a good idea to somehow hard-code a few filter IDs somewhere, because of the hard to manage Technical-Debt this causes. We currently explore a way to inverse this dependency, see T253876.

In T224802#6176402, @thiemowmde wrote:

A note from yesterdays discussion: Bad SVGs (see T216516) and most AbuseFilters (see T223288) are about files that are potentially bad. In contrast, OTRS tickets mark files that are known to be good. Therefore it appears like we can skip this OTRS check, even for the latest file revision.

However: It seems like this check is implemented as an AbuseFilter. We can not just disable all abuse filters for older file revisions, because we would disable all critical filters as well then. It's also not a good idea to somehow hard-code a few filter IDs somewhere, because of the hard to manage Technical-Debt this causes. We currently explore a way to inverse this dependency, see T253876.

Just as addition to that: A first step that we're definitely planing to implement is unblocking imports that are just triggering AbuseFilter warnings. See T253872: Respect AbuseFilter warnings triggered by imports. This will at least allow importing files again that just trigger the OTRS rule ( independent of what revision triggers it ).