Last modified: 2013-10-31 09:22:08 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27951, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25951 - AbuseFilter should be able to warn or prevent users conditionally
AbuseFilter should be able to warn or prevent users conditionally
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: High enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-16 13:26 UTC by Krinkle
Modified: 2013-10-31 09:22 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Krinkle 2010-11-16 13:26:26 UTC
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.
Comment 1 Gurch 2010-11-17 17:21:56 UTC
(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.
Comment 2 John Mark Vandenberg 2011-04-28 06:14:01 UTC
As the conditions are cached, is there a significant perf hit in having two filters with the same conditions?
Comment 3 Andrew Garrett 2012-02-10 21:28:26 UTC
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.
Comment 4 Helder 2013-07-15 21:00:17 UTC
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
Comment 5 Krinkle 2013-10-31 00:59:46 UTC
(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.
Comment 6 MZMcBride 2013-10-31 01:05:26 UTC
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.
Comment 7 Helder 2013-10-31 09:22:08 UTC
(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?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links