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?

matthew.britton wrote:

(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.

mike.lifeguard+bugs wrote:

(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.

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.

Kropotkine113 wrote:

Please see [[bugzilla:24943]] for another reason to make abusefilter's logs work like others logs.

While bug 24943 was fixed, there is still merit to comment 5 as there is no admin level suppression for edit filter log entries.

• Bug 18080 has been marked as a duplicate of this bug. ***

In T21494#240058, @bzimport wrote:

• 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.

As far as I understand it, that would make it more difficult to debug filters to detect the cause of regressions.

I think this is a good idea.

We wouldn't get rid of the abuselog database entirely, it would still be used for storing the detailed parameters. But we should store title/user/revdel/etc in the normal logging system, use it for displaying the logs, and then keep a key in the abuselog table pointing to the log entry.