Page MenuHomePhabricator

Allow moving a filter to another free number
Closed, DeclinedPublic

Description

As I understand, abuse filter checks each edit against all available active filters in ascending order with respect to their assigned number. For example an arbitrary edit will be checked against AF number 1, 2, 3, and so on.

Filters are usually created in order, too.

But some filters that are created later, have higher priority. I can think of two situations that this could happen:

  1. AF n+1 is set to disallow an edit for IP addresses and AF n is set to warn all users for that edit. It makes sense to put AF n+1 before AF n, so that if an IP address tries submitting that edit, they will see the disallowed message first and won't try again...
  2. Some abuse filters perform more critical tasks and we don't want them to be ignored because of reaching the condition limit.

If moving filters was possible, we could rearrange such filters and avoid the above issues.

Of-course this can be done manually, but there are several problems with manual copy-n-pasting:

  1. It's boring! (you'll have to copy all the fields, recheck the checkboxes..., set warning message, etc...)
  2. Their edit history is not preserved.
  3. After renaming a filter and overwriting it as described above, all the logs of the older filter will appear under the new name. This can easily lead to confusion...

Event Timeline

Dalba created this task.Apr 16 2016, 2:42 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 16 2016, 2:42 PM
He7d3r added a subscriber: He7d3r.Nov 28 2016, 11:08 AM
Pppery added a subscriber: Pppery.Mar 1 2017, 12:07 AM

Filters can be undeleted.

Huji added a subscriber: Huji.EditedMar 1 2017, 2:25 AM

I think this is the wrong solution, and the root problem is not the inability to move AFs to new numbers, but the lack of ability to specify the order in which AFs are executed. The fact that they are run based on their ID (first AF1, then AF2, etc.) is just too simplistic.

Several other tasks have been created around the same problem, for instance T20067, T49531. I think we should properly address the root cause, rather than putting band aids here and there.

Huji added a comment.Aug 27 2017, 12:27 PM

Another reason why this is a bad idea: if you move a filter that has been triggered thousands of times, then you have to update the abuse_filter_log table thousands of times too!

The correct solution is to add a new column to the abuse_filter table called execution_order. Upon filter creation it is set to the same number as the filter ID. Later, however, one can change the order in which filters are executed.

This also requires an easy-to-use front-end for re-ordering the filters in terms of their execution sequence. Wikis can have hundreds of filters, and the interface should allow re-ordering hundreds of filters easily. This is not a trivial issue.

Dalba removed a subscriber: Dalba.Aug 27 2017, 12:32 PM