Page MenuHomePhabricator

AbuseFilter should be able to warn or prevent users conditionally
Closed, DeclinedPublic

Description

Currently an abusefilter either warns, prevents or both.
But the conditions are the same.
It would prevent duplication to be able to set an abusefilter to warn for all, but only prevent non-autoconfirmed users as example.


Version: unspecified
Severity: enhancement

Details

Reference
bz25951

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:22 PM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz25951.
bzimport added a subscriber: Unknown Object (MLST).

matthew.britton wrote:

(In reply to comment #0)

Currently an abusefilter either warns, prevents or both.
But the conditions are the same.
It would prevent duplication to be able to set an abusefilter to warn for all,
but only prevent non-autoconfirmed users as example.

Does such a duplication exist at the moment? I would be very interested to see a use case that doesn't amount to unnecessary shutting out of non-autoconfirmed users.

As the conditions are cached, is there a significant perf hit in having two filters with the same conditions?

This would be far too complicated for an already complicated extension. I'm inclined to WONTFIX, unless somebody can come up with a sane UI and data model for this.

I noticed a similar user case on Portuguese Wikipedia, where there are very similar filters detecting small new pages, one of them disalowing the edit (for the smaller pages) and the other just warning (for a little bigger pages):
https://pt.wikipedia.org/wiki/Special:AbuseFilter/history/66/item/1418
https://pt.wikipedia.org/wiki/Special:AbuseFilter/history/53/item/1436

(In reply to comment #3)

This would be far too complicated for an already complicated extension. I'm
inclined to WONTFIX, unless somebody can come up with a sane UI and data
model for this.

Agreed.

It's a little strange that AbuseFilter implements a lot of "if" logic already in a flexible manner, but the "then" logic is limited and less flexible. Moving all of the logic to the text input area would probably be easiest.

(In reply to comment #6)

It's a little strange that AbuseFilter implements a lot of "if" logic already
in a flexible manner, but the "then" logic is limited and less flexible.
Moving
all of the logic to the text input area would probably be easiest.

Maybe when/if it is switched to using Lua (bug 47512), this will be easier to implement?