Page MenuHomePhabricator

Provide a way to move a file to Commons when it has an OTRS tag
Open, Needs TriagePublic

Description

I was trying to move to commons a file with an OTRS tag added by an OTRS agent, but wasn't able to do so due to some abuse filter warning. The warning says "You are trying to add a OTRS permission tag to this page. In general, such tags should only be added by OTRS members."

And then it says that "You may press 'Save page' again if you like to save this edit.' But there's no "save page" button, there's only the one that says "Import", and whenever you press it, you get the warning again and again.

Even if you try to "Edit File Info" and temporarily remove the OTRS tag, the warning persists, and doesn't let you import the file.

The only way you could move such a file to Commons seems to be the one when you preliminarily remove the OTRS tag, then press the button to move to Commons, and revert your own edit after the file is imported. But this way is kind of counterproductive.

Event Timeline

Restricted Application added a project: TCB-Team. · View Herald TranscriptJun 1 2019, 8:00 AM
Restricted Application added a subscriber: Base. · View Herald Transcript
Piramidion updated the task description. (Show Details)Jun 1 2019, 8:02 AM
Krenair added a subscriber: Krenair.Jun 1 2019, 1:19 PM

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.

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.

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 ).