Last modified: 2013-03-10 13:37:38 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.
This also applies to material subsequently removed with RevisionDelete (i.e. the new "Oversight").
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).
OK, can someone give a url? Thanks.
Doesn't seem to be an easy way to do this. Revision ID is not tracking in the var dumps.
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.
(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.
(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.
(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?
(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.
(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.
(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.
[Batch change] Removing Dave McCabe from CC, who I somehow managed to add to the CC list of 12 bugs assigned to me.
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.
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.
(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?
Bump. More oversighted material needs to be removed. Any timeline on this ticket?
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?
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?
I fixed this today. It won't be active on Wikimedia sites for some weeks.
(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?
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.
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.
