Last modified: 2009-04-23 05:57:46 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 T20490, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18490 - Some Abuse Filter log entries shouldn't be there as the actions doesn't match the stated filter
Some Abuse Filter log entries shouldn't be there as the actions doesn't match...
Status: RESOLVED WORKSFORME
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Andrew Garrett
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-17 02:16 UTC by Mike.lifeguard
Modified: 2009-04-23 05:57 UTC (History)
2 users (show)

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


Attachments

Description Mike.lifeguard 2009-04-17 02:16:05 UTC
For example on meta:

# 03:26, 25 March 2009: Krims (Talk | contribs | block) triggered filter 17, performing the action "edit" on User talk:Krims. Actions taken: Block autopromote; Filter description: Vandalistic edit summaries (details) (examine)

But if you look at http://meta.wikimedia.org/w/index.php?title=Special:AbuseLog&details=139 there is nothing that should match filter 17. Furthermore, testing filter 17 at http://meta.wikimedia.org/wiki/Special:AbuseFilter/examine/log/139 shows that in fact the edit *doesn't* match filter 17 - so why is it logged?
Comment 1 Gurch 2009-04-18 20:57:05 UTC
quite serious if true
Comment 3 Andrew Garrett 2009-04-23 03:46:07 UTC
Given test case matches for me, it's because of a buggy filter.

Remember to test against the version of the filter which was in effect at the time, in this case, http://meta.wikimedia.org/wiki/Special:AbuseFilter/history/17/item/90

("X" rlike summary) will *always* match for empty summaries regardless of what "X" is.

For the expected result, reverse "X" and summary.
Comment 4 Mike.lifeguard 2009-04-23 05:57:46 UTC
An chance we can get some indication when the log entry applies to an old version of the filter rather than the current one? This is *very* confusing otherwise. Either the revision number or just top/not top would be excellent.

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


Navigation
Links