Last modified: 2014-02-13 03:49:59 UTC
There have been several edits that triggered multiple AbuseFilters. This is particularly annoying for the people checking on them since unless you're looking for it, there's no indication why an edit isn't showing up in the editor's contribution log unless you figured out another filter was triggered that stopped the edit from going through. Case in point: Filter 3 catches massive page blanking by new users. Filter 43 catches removal of reference tags by new users. When a massive blanking is done, both filters trigger, but there are instances when the blanking is not large enough to trigger filter 3. So both filters are needed. It would be very helpful if we were able to ignore a certain filter if another one was already triggered. This is easy to achieve if you simply base it on the filter number, but I think the servers could be saved from more strain by ordering the filters in a particular decision tree order that avoids anything already checked for earlier in the tree from being executed.
Some tools for filter interaction might be nice, yeah. Ideas: * Dependencies for filters. * Variables for filters_matched. * Some kind of scoring system.
Marking this bug as Lowest priority. I've done this in a batch to (usually enhancement request) bugs where: * It is not clear that this bug should be fixed. * It is not clear how to fix this bug. * There are difficulties or complications in fixing this bug, which are not justified by the importance of the bug. * This is an extremely minor bug that could not be fixed in a few lines of code. If you're interested in having one of these bugs fixed, your best bet is to write the patch yourself.
Andrew Garrett, what do you mean by "Some kind of scoring system"?