Last modified: 2013-03-10 13:37:38 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 T20043, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18043 - AbuseFilter log entries cannot be redacted/suppressed
AbuseFilter log entries cannot be redacted/suppressed
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Andrew Garrett
https://secure.wikimedia.org/wikipedi...
:
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2009-03-19 01:09 UTC by WODUP
Modified: 2013-03-10 13:37 UTC (History)
15 users (show)

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


Attachments

Description WODUP 2009-03-19 01:09:21 UTC
An action performed on a page that triggers the abuse filter is logged, but the content of the page in the log remains visible after the page is deleted.
Comment 1 Robert Rohde 2009-03-25 15:42:05 UTC
This also applies to material subsequently removed with RevisionDelete (i.e. the new "Oversight").
Comment 2 Mike.lifeguard 2009-04-02 18:08:46 UTC
Sounds like deletion needs to purge the relevant content from AbuseLog. Alternatively, mark it as deleted, and let only those with viewdeleted see it (which would be something like bug 18091).
Comment 3 Aaron Schulz 2009-04-02 18:09:56 UTC
OK, can someone give a url? Thanks.
Comment 4 Aaron Schulz 2009-04-03 01:24:04 UTC
Doesn't seem to be an easy way to do this. Revision ID is not tracking in the var dumps.
Comment 5 Andrew Garrett 2009-04-03 01:28:54 UTC
You could just delete all log entries for a particular page when that page is deleted.

Wouldn't deal perfectly with undeletion, of course, and I suppose we could add a per-log-entry deletion facility.

Planning to add an afl_deleted field in the abuse filter log with a raft of schema changes coming in the next few weeks.
Comment 6 Robert Rohde 2009-04-03 03:02:18 UTC
(In reply to comment #5)
> You could just delete all log entries for a particular page when that page is
> deleted.

There is an edge case where the abuse filter log is recording an attempted edit to a non-existent page that was disallowed or aborted.  In which case the page was never created, and consequently was also never deleted.  I know of at least one case where the abuse log for such an attempted edit contains oversight grade material.

That case probably needs to be handled at the time when such a log entry is accessed.
Comment 7 Andrew Garrett 2009-04-03 03:07:22 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > You could just delete all log entries for a particular page when that page is
> > deleted.
> 
> There is an edge case where the abuse filter log is recording an attempted edit
> to a non-existent page that was disallowed or aborted.  In which case the page
> was never created, and consequently was also never deleted.  I know of at least
> one case where the abuse log for such an attempted edit contains oversight
> grade material.

As I say, a per-log deletion button would deal with this situation.
Comment 8 Mike.lifeguard 2009-04-03 11:38:22 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > You could just delete all log entries for a particular page when that page is
> > > deleted.
> > 
> > There is an edge case where the abuse filter log is recording an attempted edit
> > to a non-existent page that was disallowed or aborted.  In which case the page
> > was never created, and consequently was also never deleted.  I know of at least
> > one case where the abuse log for such an attempted edit contains oversight
> > grade material.
> 
> As I say, a per-log deletion button would deal with this situation.
> 

So in the case of a normal deleted page you want sysops to go find the log entries or whatever and delete them separately?
Comment 9 WODUP 2009-04-03 18:15:19 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > (In reply to comment #5)
> > > > You could just delete all log entries for a particular page when that page is
> > > > deleted.
> > > 
> > > There is an edge case where the abuse filter log is recording an attempted edit
> > > to a non-existent page that was disallowed or aborted.  In which case the page
> > > was never created, and consequently was also never deleted.  I know of at least
> > > one case where the abuse log for such an attempted edit contains oversight
> > > grade material.
> > 
> > As I say, a per-log deletion button would deal with this situation.
> > 
> 
> So in the case of a normal deleted page you want sysops to go find the log
> entries or whatever and delete them separately?
> 

Perhaps delete from the log when a logged action is deleted from the page or oversighted, but also have a delete button available to delete only the action in the log, in case the edit was never completed.
Comment 10 Andrew Garrett 2009-04-05 04:50:19 UTC
(In reply to comment #9)
> Perhaps delete from the log when a logged action is deleted from the page or
> oversighted, but also have a delete button available to delete only the action
> in the log, in case the edit was never completed.

That's what I said five comments ago.
Comment 11 Andrew Garrett 2009-07-16 17:04:35 UTC
(Batch change)

These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.
Comment 12 Andrew Garrett 2009-08-14 12:37:58 UTC
[Batch change]

Removing Dave McCabe from CC, who I somehow managed to add to the CC list of 12 bugs assigned to me.
Comment 13 Happy-melon 2009-11-12 22:33:43 UTC
Kicking this. There are several open threads on oversight-l regarding material in AbuseFilter log entries that urgently needs suppression.  An afl_deleted column and, at least, the options hide-from-nonadmins and hide-from-nonoversighers are very badly needed.
Comment 14 Anakin 2009-11-26 19:44:13 UTC
In the mean time, how about just obscuring viewing of all log entries older than say, 1 week, except to those with abusefilter, oversight and/or sysop permissions? It would reduce the scope for trouble with log entries without increasing the workload for those tasked with oversighting stuff.
Comment 15 Salem 2010-01-12 02:20:17 UTC
(In reply to comment #14)
> In the mean time, how about just obscuring viewing of all log entries older
> than say, 1 week, except to those with abusefilter, oversight and/or sysop
> permissions? It would reduce the scope for trouble with log entries without
> increasing the workload for those tasked with oversighting stuff.
> 

What next? Obscuring user contributions from non-admins?
Comment 16 KnightLago 2010-02-15 21:37:00 UTC
Bump. More oversighted material needs to be removed. Any timeline on this ticket?
Comment 17 Risker 2010-05-16 15:54:07 UTC
Bump again. Any progress on this?  More oversight-grade entries in the abuse logs. This is a recurrent and chronic issue, so a method for oversighters to suppress these entries is needed. We shouldn't be needing to run to a developer whenever a filter captures private data. More particularly, right now filter developers are holding off on creating filters that are designed to capture certain recurring vandalism that contains oversight-level data because they know the abuse filter logs can't be oversighted in the usual way. 

Can we get this moved up in priority please?
Comment 18 HJ Mitchell 2010-06-26 01:47:59 UTC
Another bump. There's more stuff that ideally should be oversighted or at least removed from public view in the abuse logs and a lot of potentially very useful filters are on hold indefinitely because they would catch material that would need to be removed from public view. Any chance a higher priority can be given to this?
Comment 19 Andrew Garrett 2010-06-26 01:49:46 UTC
I fixed this today. It won't be active on Wikimedia sites for some weeks.
Comment 20 HJ Mitchell 2010-06-26 02:48:48 UTC
(In reply to comment #19)
> I fixed this today. It won't be active on Wikimedia sites for some weeks.

That's good to hear, thank you very much. Is there any chance you could give a more specific educated guess as to how long it might be for informational purposes?
Comment 21 Happy-melon 2010-06-26 10:16:22 UTC
It was done in r68584.  Looks like some small schema changes need to be made to the abuse_filter_log table, which is 2,956,540 rows.
Comment 22 Thehelpfulone 2011-05-19 21:01:51 UTC
Note, https://bugzilla.wikimedia.org/show_bug.cgi?id=28633 is now related to this. I believe this should also be fixed. Please comment/vote etc. :) THO.

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


Navigation
Links