Last modified: 2006-12-25 02:40:28 UTC
I propuse a new field in CheckUser.php in which the checkuser should provide small info about his/her check. This will help the other checkuser to check the person which do the check (according to the policy) and could be helpfull. Original proposed by Vlad@rowiki
Created attachment 2813 [details] Add reason box and a "list users only" option to checkuser
Comment on attachment 2813 [details] Add reason box and a "list users only" option to checkuser That's not a patch, it's a whole new file. Please submit a *diff* against the existing file. Your Subversion client can do this, as can diff -u on Unix/Linux etc.
Created attachment 2814 [details] patch to add "list users only" and "reason" box to checkuser OK, this should be in patch format now. Sorry.
I'd rather see the feature split into a new function, and presented as such - a different submit button, perhaps, for the visual cue.
(In reply to comment #4) > I'd rather see the feature split into a new function, and presented as such - a > different submit button, perhaps, for the visual cue. I am not sure what you mean. I was thinking of having it like the summary box for edits, exept having a submit button for each operation (user or IP). Like at http://www.mediawiki.org/wiki/User:Voice_of_All/CheckUser2.0. The summary is an auxilary to either of the twain, so I don't see why it would need its own submit button. Can you expand on what you mean by "visual cue"? Maybe I code make some code changes, but I really want to keep this simple.
I was on about the "usernames used" bit, since you seem to have presented two fixes in the same patch...which is not always a good idea.
Created attachment 2842 [details] Patch to add "reason" box and "list usernames only option" OK, I've taken Rob's advice and forked the interface (see my mediawiki.org subpage) and the functions. Having done that, I've added a bit of info to the "get users" results, inclusing time framing, a count of the edits, and the user tool links.
Created attachment 2843 [details] update; cleaned up some things
Created attachment 2844 [details] upate; clean up form
Created attachment 2852 [details] Summary patch for checkuser (see http://www.mediawiki.org/wiki/User:Voice_of_All/CheckUser2.0)
Created attachment 2854 [details] Summary patch; pretty up form and fixed two small bugs
A few quick notes: - some spacing and capitalization quirks; not a big deal but it's nice to be clean ;) - the form HTML isn't XHTML-clean. the old one wasn't either, but it's good to try to clean that up - i18n appears incomplete; "<checkuserheader>" appears at top of form - if I just hit 'enter' in the form without inputting anything, i get a php warning: <b>Notice</b>: Undefined variable: counter in <b>/opt/web/pages/trunk/extensions/CheckUser/CheckUser_body.php</b> on line <b>130</b><br /> - it's not clear which button will be active when i hit 'enter' in the ip field - "Get users" mode seems to have some bugs, spews out php warnings: <b>Notice</b>: Undefined index: WikiSysop in <b>/opt/web/pages/trunk/extensions/CheckUser/CheckUser_body.php</b> on line <b>162</b><br /> etc for each username that appears - hitting 'enter' in the username field appears to have no effect; it's triggering the 'Get edits' for IP button, at least in Firefox - the 'search' box on the log view submits to an incorrect address on server with query string-based article URLs; the target page needs to be added as a hidden field to the form
Fixes: *I've spaced the form out a bit better *Removed the header (maybe later) *The 3 query types our only ran if the corresponding input is given, so pressing "enter" either takes you to the normal checkuser page without running any queries, or, if there is a valid input pair (like "get users" and an IP is given) it will run. This should fix the botched query problems. *$Counter is always defined (rather than only when results are returned) Todo: *XHTML compatibility: Not really sure how to do this *Search box address: Brion, could you explain this more, and how can I repeat the error? I don't understand what the bug is but I'd like to fix it.
Also, I never got the "Undefined index" error on my test wiki. The output appears fine and no php errors show (I have php set to show any error or notice). I did change key checker to use an appropriate function, array_key_exists(), but I don't know if that fixes the bug because I never experienced it.
XHTML: use well-formed XML in output. A quick way to test this is to set $wgMimeType = 'application/xhtml+xml'; If you're using Firefox/Mozilla or Opera, this will nicely run output through a proper XML parser and spit nasty errors at you if your code is bad. You can also do a full validity check with validator.w3.org or something for more detailed checks. Common errors are unclosed tags, misnested tags, and unquoted attributes (for instance on the table tags). Um, did you want to attach the updated patch so it could be tested? :)
The search issue: a) The action URL on the form is the default article URL for Special:CheckUser. b) The form submits by GET, meaning that form fields are formatted into a query string on the target URL. If $wgArticlePath uses the query string to specify titles, the result is that the query string with the title is stripped from the URL and replaced with the fields in the form. Since the form doesn't include a "title" field, the data is submitted to the default main page instead of to Special:CheckUser. For this sort of thing, use $wgScript as the target URL and pass the special page name in a hidden title field, ensuring it ends up on the submission URL.
Created attachment 2870 [details] update summary patch; XHTML valid, and script title fixed
(The other fixes are included in the last patch as well)
I get no results when hitting 'enter' in the user field... Actually, I get edits-for-ip results if the IP field is also filled out at the time -- very confusing when trying to narrow down results or such. There's still no indication which button will be default when I hit enter in the IP field. I get a new notice error when listing users for an IP: <br /> <b>Notice</b>: Undefined variable: s in <b>/opt/web/pages/trunk/extensions/CheckUser/CheckUser_body.php</b> on line <b>177</b><br /> The behavior when clicking on an IP in the ips-for-user list is a bit non-obvious to me. I guess it pre-fills the form for an IP-to-edit check? Spacing/alignment on the form is a bit off; 'IP address' is vertically centered between the input box and buttons, but 'Username' is aligned with the input box alone. 'Username:' is also flush against the input box, and should probably have some free space. The new code doesn't insert <li>...</li> wrappers into the log file, but doesn't strip the old ones when reading log entries. This leads to incorrect output display, with apparently blank lines or other oddities.
Most of the other problems seem fixed, though. Good job! Sorry, didn't want to be all negative there. ;)
Created attachment 2876 [details] Update; $s initialized, alignment stuff, User button works with enter OK, I've switched the places of IP and User after doing some other alignment stuff. This way enter works for User checks and you usually check names before checking IPs. Pressing "enter" for IPs has no affect; it returns to the standard checkuser page. "Enter" only works with simple inputs, browsers tend to just pick one submit tab and choose it (and they pick different ones, Opera and Mozilla). Opera at least highlights the one it will submit. I could have "get edits" say "(default)" and make a form for both IPs and Users which would allow enter to work fully *where* I not also having a reason box. The only way around that would be to have two forms and a silly reason box for each :).
Oh, also see http://www.mediawiki.org/wiki/User:Voice_of_All/CheckUser2.0. The <li> tags need to be removing from the file (open it and use replace all or something?). That way it will parse correctly.
What benefit does the new parse method have over the old one, i.e. exactly what benefit would we encounter after hacking about with a huge log file?
The search box should only search for things visible in the log. Since you don't see formatting tags, then search shouldn't pick up them. This can be done by having only delimeters as non-visible characters in the log, like \n. The <li> tags are imploded in when viewed. This means that if you type in "<li>", "<", or ">", you won't get a the whole log. It also makes the file a tad smaller, but thats not the main reason.
The enter behavior is just really weird to me. I'm also bugged more and more by the reason box being above, when it's below in other forms. Two separate sub-forms probably makes more sense than unpredictable behavior in a unified form. I'd also prefer compatibility with existing log files; there's no reason to break compatibility.
Created attachment 2902 [details] Switch back to old log format, hacks to get enter to "work" OK, the search now uses a hack to ignore the <li> tags, so the format is back to the old way. As for the reason box, its best left on top as in other forms, there is only one "OK" box right after the reason box. In this case, the reason box can't have the "OK" after it, so by having it on bottom, it looks strange as all the submit buttons are above it, making it look more optional and trivial. This is a lot of patch revisions, I hope this the last one :) ...
Oh, and "get edits", no says "get edits (default)". The enter hacks didn't require a separate reason box fortunetely.
One last thing to mention, dates show like "07:29, 19 December 2006" only. It no longer formats it based on the user doing it, which resulted in numerous different formats (which apparently somewhat annoying).
Applied on r18552.
Created attachment 2944 [details] Improve hack for "enter" key More predictable behavoir when not using enter
Created attachment 2945 [details] Improve hack for "enter" key Diff against svn hopefully
