| Morgankevinj | |
| Jul 19 2019, 3:28 PM |
| F30016146: T228526.png | |
| Aug 13 2019, 10:12 AM |
Steps to Reproduce:
see https://commons.wikimedia.org/w/index.php?title=File:Test_image,_not_mickey.png&action=history
run batch testing of filter 69 on File:Test_image,_not_mickey.png
Actual Results:
The tag "OTRS permission added by non-OTRS member" is not consistently applied by filter 69 but the batch testing feature says the changes match the filter.
Expected Results:
The tag "OTRS permission added by non-OTRS member" should be applied to changes that match the filter.
First of all, some links for testing ease:
Note that "inconsistently applied" doesn't say much :-) Nevertheless, I guess that what you mean is, the filter is not tagging edits by Alexis Reggae although batch testing says those edit do match the filter.
Currently I cannot test it locally, although the bug does seem to be a thing.
Now, some things that come to mind. In order to apply tags, AF saves some data in AbuseFilter::$tagsToSet. Then, when the RC is saved, we use the onRecentChangeSave hook to check whether we had buffered any tag for the RC being saved. So:
Some related code has also been refactored recently, but I don't think it's related. Of note, tagging is working sometimes (look for other edits on the same page).
Huh, ignore the rant above. The filter isn't even matching the action, so it doesn't have to do with tags.
I cannot check the filter on-wiki at the moment, so I'd like to know whether the filter is supposed to match those edits (and thus the problem is that the filter is not matching the action), or not (and thus it's a problem in batchtest, where those edits shouldn't match).
Yes, what I asked is whether the filter is supposed to match that action, but I guess it is.
First of all, an unrelated note: the filter uses lcase(...) rlike otrstemplates, but otrstemplates is a regex containing uppercase characters, so it won't ever match. Instead, I suggest to remove the lcase's and replace rlike with irlike.
Another mostly unrelated thing is that commons' filter 69 is one of the slow ones, and is sometimes reported as taking more than 800ms on logstash. But this cannot affect whether it matches the action.
Also, there are no AF-related entries on logstash around the time of this edit. So I believe the cause is not obvious. The only change that could have potentially caused the problem is this one, but I don't see how it could be really related to this specific case.
As I said above, I cannot test this bug locally these days, and I'm afraid that's the only way to understand it a little bit more.
Under batch testing it says the edit matched the matches the filter but the was the tag was not applied and there was no entry in the abuse log. The same thing is also happening with AbuseFilter 70 and this diff.
If the filters were copied over to https://commons.wikimedia.beta.wmflabs.org would you be able to test this there?
I'll test locally and provide a specific solution for commons filter as soon as possible.
I did it by myself. I tried to restore Alexis Reggae's version (which previously didn't match the filter) and I got warned. So this is now working as expected.
As a side note, the warning display is broken, see below:
The warning message should probably be fixed.
I did it by myself. I tried to restore Alexis Reggae's version (which previously didn't match the filter) and I got warned. So this is now working as expected.
As a side note, the warning display is broken, see below:
The warning message should probably be fixed.
This is because there was a second filter enabled, which had set the same warning. This has been fixed (the original filter author disabled the filter).