Last modified: 2014-02-12 23:38:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 19494 - Abuse Filter log should appear in Special:Log and work like other logs
Abuse Filter log should appear in Special:Log and work like other logs
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 18080 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-03 10:10 UTC by Gurch
Modified: 2014-02-12 23:38 UTC (History)
5 users (show)

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


Attachments

Description Gurch 2009-07-03 10:10:18 UTC
The Abuse Filter log should work like every other log, not have its own separate page. Pretty sure this was brought up before but I can't find the bug for it, so making one.
Comment 1 Andrew Garrett 2009-07-03 10:15:54 UTC
I'm not convinced:

- Would be a reduction in searching functionality. Regular logs are only searchable by user and page, abuse filter log is searchable by filter, user, page and so on.
- Logging table does not have space for large amounts of structured data, such as the variables which are stored in the abuse filter log.

There are probably other reasons. What reasons are there in favour of the proposed change?
Comment 2 Gurch 2009-07-03 11:24:38 UTC
(In reply to comment #1)
> I'm not convinced:
> 
> - Would be a reduction in searching functionality. Regular logs are only
> searchable by user and page, abuse filter log is searchable by filter, user,
> page and so on.

Regular logs are searchable by tag, only thing that can tag things (at the moment) is abuse filters. So there is no loss of functionality

> - Logging table does not have space for large amounts of structured data, such
> as the variables which are stored in the abuse filter log.

A lot of that data shouldn't really be kept permanently anyway. IMO it should be dropped when recent changes are, and [[Special:AbuseFilter/examine]] should be the interface for accessing it (just needs an extra field to enter a revision ID for those interested in a specific revision)

> There are probably other reasons. What reasons are there in favour of the
> proposed change?

* Consistency
* Hits would show up in IRC feed
* Would be another step towards actually making the thing usable for recent changes patrolling
* without a separate "abuse log" link in contributions, people would be less likely to be offended by hits in their log from broken filters and change all mentions of the extension to "Edit Filter", which is as confusing as it is incorrect, as just happened on en.wikipedia.

Comment 3 Mike.lifeguard 2009-07-03 23:07:12 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > - Would be a reduction in searching functionality. Regular logs are only
> > searchable by user and page, abuse filter log is searchable by filter, user,
> > page and so on.
> 
> Regular logs are searchable by tag, only thing that can tag things (at the
> moment) is abuse filters. So there is no loss of functionality

I think that does represent a loss of functionality. However, if this were a supplement to the full log, that'd be more than acceptable. I wouldn't want to see [[Special:AbuseFilter/Log]] disappear, but sending extracts to the normal log would make a lot of sense in terms of usability and workflow, as I describe below.

> A lot of that data shouldn't really be kept permanently anyway. IMO it should
> be dropped when recent changes are

I agree with you here, but I don't think that's an argument for putting this data in the normal log.

> * Hits would show up in IRC feed

See bug 18080 for that; I've marked it as depending on this one (although I guess it may be possible to implement 18080 without this one -- Andrew may wish to remove the depends depending on any implementation plans that are made).

> * Would be another step towards actually making the thing usable for recent
> changes patrolling

This, I think, is the convincing argument. AbuseFilter has serious workflow issues - making is usable for patrollers needs to be a prime objective. Sending extracts of [[Special:AbuseFilter/Log]] to [[Special:Log/abusefilter]] would achieve that goal at least in part. Those log entries would as I say be *extracts* of the full log, and would simply link to [[Special:AbuseFilter/Log]] with appropriate parameters (or maybe [[Special:AbuseFilter/examine]]?) for anyone wanting to see further details.
Comment 4 Andrew Garrett 2009-07-16 16:47:51 UTC
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.
Comment 5 Kropotkine113 2010-08-26 12:49:31 UTC
Please see [[bugzilla:24943]] for another reason to make abusefilter's logs work like others logs.
Comment 6 John Mark Vandenberg 2011-02-23 05:14:43 UTC
While bug 24943 was fixed, there is still merit to comment 5 as there is no admin level suppression for edit filter log entries.
Comment 7 Krinkle 2012-02-22 18:11:26 UTC
*** Bug 18080 has been marked as a duplicate of this bug. ***

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


Navigation
Links