Last modified: 2013-11-08 12:05:12 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 9858 - Recursive checkuser featured needed
Recursive checkuser featured needed
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
unspecified
All All
: Normal enhancement with 15 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-09 19:09 UTC by Mark Pellegrini
Modified: 2013-11-08 12:05 UTC (History)
9 users (show)

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


Attachments

Description Mark Pellegrini 2007-05-09 19:09:42 UTC
Following a recent checkuser request that required over 3 hours of tedious
manual labor (which I never did finish) - [[Wikipedia:Requests for
checkuser/Case/Artaxiad]] - it's become obvious to me that checkuser needs a
recursion feature. 

The feature should take a username or IP address, and repeatedly run checkuser
on all subsequent matches to a certain user-specified recursion depth. Repeated
entries (that is, a user or IP address that appears multiple times in the tree)
should be excluded. 

The output should be a tree-list form, as shown at
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_checkuser/Case/Artaxiad#Raw_data
(Note - the recursion depth in that case is 17). Usernames and IP addresses
should be linked to their respective user pages.
Comment 1 Mark Pellegrini 2007-10-24 04:14:08 UTC
I spent almost another hour tonight on http://en.wikipedia.org/wiki/Wikipedia:Requests_for_checkuser/Case/Libertyvalley
Comment 2 Aaron Schulz 2008-01-12 06:00:04 UTC
For performance reasons, unless Tim thinks it's OK.
Comment 3 Larry Pieniazek 2008-01-12 15:43:22 UTC
I'd like to ask that this WONTFIX decision be revisited. It is OK, in my view, if the request itself is throttled to not put too much of a load on the system, and takes considerable elapsed time to return results, because the alternative of doing it by hand takes far more elapsed time.
Comment 4 Tim Starling 2008-01-14 00:52:09 UTC
I don't see why it would be a performance problem, as long as the total result set size was limited.
Comment 5 Larry Pieniazek 2008-01-14 01:51:28 UTC
So can it be reopened then, or do you need a new bug submitted? The choices I see (as a non developer) don't admit of reopening via change resolution to ____ , but I'll be happy to check "reopen bug" instead... I just think maybe one of the devs should do it, I don't want to overstep.
Comment 6 Aaron Schulz 2008-01-14 02:16:04 UTC
My other problem with this is that it would be giving a very incomplete report, possibly with false negatives with no context. I suppose it is not useful enough that I'd want to code it...but if someone else wants too they can. 

Re-opening per Tim's comment.
Comment 7 Aaron Schulz 2008-01-14 02:29:17 UTC
(In reply to comment #6)
> My other problem with this is that it would be giving a very incomplete report,
> possibly with false negatives with no context. I suppose it is not useful
> enough that I'd want to code it...but if someone else wants too they can. 
> 
> Re-opening per Tim's comment.
> 

Opps, I meant "false positives", though there would be even more "false negatives" (as users' IPs don't stay exactly the same for long).
Comment 8 Larry Pieniazek 2008-01-14 02:36:34 UTC
Thanks for the reopen. Perhaps the requirement wasn't stated clearly enough? This is just automating the "walking the tree" we do now in many cases. Judgement in interpreting the results (and deciding what further explorations to do or not do) would still be just as required. and the tree walking we do now is exactly as vulnerable (no more, no less) to false negatives and false positives as if it were automated. But getting the report 3 levels deep on one page instead of spread out over 35 tabs (which required 35 separate checks) makes our work a bit easier. I think I would make the suppression of repetition an option though, I probably would run the check with that suppression turned off.
Comment 9 Aaron Schulz 2008-01-14 02:42:41 UTC
You will still need to check CIDRs rather than single IPs. Also, a shear list alone doesn't have enough context to spot out false positives. I suppose the user can then check those users/IPs.

It could occasionally be a decent starting point for catching a few users in large sock farms, like running a large fish net throw the water.
Comment 10 Mark Pellegrini 2008-01-23 16:15:39 UTC
Also, the ability to input a list of usernames into recursive checkuser (instead of just one) would be very helpful. 
Comment 11 Dweller 2008-01-23 16:52:53 UTC
Anything that reduces the legwork of complex Checkuser cases will be great. Perhaps I'm speaking from ignorance here (I'm not a Checkuser myself) but it seems to me it's not just a matter of time-saving, but surely also that the increased automation will enable the Checkusers to put their intellect into checking the results for false positives/negatives, rather than worrying about running the processes.
Comment 12 Mark Pellegrini 2008-02-06 16:06:06 UTC
I filed another feature request - bug 12808 - which is related to this one. Preferably both could be implemented in a single patch. 
Comment 13 AGK 2012-06-06 22:11:19 UTC
Bumped up to *high*, given the obvious necessity for a checkuser interface that isn't second in tediousness only to running the queries by hand against the db.
Comment 14 Kunal Mehta (Legoktm) 2013-11-08 06:38:34 UTC
(In reply to comment #13)
> Bumped up to *high*, given the obvious necessity for a checkuser interface
> that
> isn't second in tediousness only to running the queries by hand against the
> db.

I honestly don't think this is high on any developer's priorities. If there are other improvements to the CU interface that can be made, it would be helpful to file them as separate bugs.

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


Navigation
Links