Last modified: 2013-12-27 10:35:34 UTC
The abusefilter saved the ip address for each logged action. You can see that ip address with the abusefilter-private user right, but that right is not used on wmf wikis, because it provides unlogged access to user IP addresses of each logged action. To see ip addresses of users the wmf wikis are using the CheckUser extension, which restricted and logged the access. So in my opinion each entry of the abuselog should also create an entry for CheckUser, to make the ip address of logged actions searchable. It is possible to include the logged action from abusefilter into the CheckUser report? Thanks.
User Trijnstel also requested this. He additionally added: "It's not my intention to (automatically?) check all abusefilter logs (which was something the abusefilter-private right did). I would like to see the logs itself in the "edits" section of the CheckUser form. For example: if you check a user on his edits, you'll get his regular edits, any log actions such as account creation and emails he send. But you doesn't see the abuse log entries. And that's something I would like to see in the results. Now the log entries are completely ignored, just as if they didn't exist. You don't see them via the edits, nor do you see them via the users section. So I don't want to check on abuse log entries - like IP's/Edits/Users/Abuse Log; I only want to have the abuse log entries visible in the edits section."
*** Bug 39343 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > *** Bug 39343 has been marked as a duplicate of this bug. *** Right number? Because I am getting "You are not authorized to access bug #39343.", if that is the right bug, please make it visibe. Thanks.
Bug 39343 was opened as a security bug, and contains private information of a spam bot that the reporter was using as an example. I included the relevant pieces, without the private data, in Comment #1. Sorry for the confusion!
The easiest way to do this would be to send AbuseFilter hits to RecentChanges, at which point CheckUser would pick them up, however that would also cause them to show up in RecentChanges, which might not be what is wanted (also the public vs. private issue). The other way would be to have AF manually create the RecentChanges object and have the CheckUser extension call a AF hook (that would need to be written) which gets it.
In the long term, the best way going forward would be to not have the CheckUser extension rely on RecentChanges. It seems to me that as for late we're getting more and more tools that do not log to the RecentChanges (Abuse filter, Article Feedback Tool)
Change 92053 had a related patch set uploaded by Legoktm: Send AbuseFilter hits to CheckUser https://gerrit.wikimedia.org/r/92053
Change 92053 merged by jenkins-bot: Send AbuseFilter hits to CheckUser https://gerrit.wikimedia.org/r/92053
Should go out with 1.23wmf9. Note that only filter hits after this change is deployed will show up in CU results.
Sweeeeet. Thanks.