Last modified: 2006-12-25 02:40:28 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 5044 - Summaries for CheckUser.php
Summaries for CheckUser.php
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-19 19:21 UTC by Mihai Floran
Modified: 2006-12-25 02:40 UTC (History)
2 users (show)

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


Attachments
Add reason box and a "list users only" option to checkuser (8.69 KB, text/plain)
2006-12-03 01:53 UTC, Aaron Schulz
Details
patch to add "list users only" and "reason" box to checkuser (4.40 KB, patch)
2006-12-03 04:57 UTC, Aaron Schulz
Details
Patch to add "reason" box and "list usernames only option" (6.25 KB, patch)
2006-12-09 03:01 UTC, Aaron Schulz
Details
update; cleaned up some things (6.13 KB, patch)
2006-12-09 03:08 UTC, Aaron Schulz
Details
upate; clean up form (6.13 KB, patch)
2006-12-09 05:16 UTC, Aaron Schulz
Details
Summary patch for checkuser (see http://www.mediawiki.org/wiki/User:Voice_of_All/CheckUser2.0) (13.45 KB, patch)
2006-12-12 23:20 UTC, Aaron Schulz
Details
Summary patch; pretty up form and fixed two small bugs (13.90 KB, patch)
2006-12-13 02:58 UTC, Aaron Schulz
Details
update summary patch; XHTML valid, and script title fixed (14.52 KB, patch)
2006-12-15 19:06 UTC, Aaron Schulz
Details
Update; $s initialized, alignment stuff, User button works with enter (14.32 KB, patch)
2006-12-16 09:30 UTC, Aaron Schulz
Details
Switch back to old log format, hacks to get enter to "work" (14.61 KB, patch)
2006-12-19 08:10 UTC, Aaron Schulz
Details
Improve hack for "enter" key (14.88 KB, patch)
2006-12-25 02:12 UTC, Aaron Schulz
Details
Improve hack for "enter" key (2.39 KB, patch)
2006-12-25 02:40 UTC, Aaron Schulz
Details

Description Mihai Floran 2006-02-19 19:21:50 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
Comment 1 Aaron Schulz 2006-12-03 01:53:39 UTC
Created attachment 2813 [details]
Add reason box and a "list users only" option to checkuser
Comment 2 Rob Church 2006-12-03 03:07:25 UTC
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.
Comment 3 Aaron Schulz 2006-12-03 04:57:20 UTC
Created attachment 2814 [details]
patch to add "list users only" and "reason" box to checkuser

OK, this should be in patch format now. Sorry.
Comment 4 Rob Church 2006-12-03 07:29:48 UTC
I'd rather see the feature split into a new function, and presented as such - a
different submit button, perhaps, for the visual cue.
Comment 5 Aaron Schulz 2006-12-04 01:45:13 UTC
(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.
Comment 6 Rob Church 2006-12-04 08:14:20 UTC
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.
Comment 7 Aaron Schulz 2006-12-09 03:01:16 UTC
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.
Comment 8 Aaron Schulz 2006-12-09 03:08:41 UTC
Created attachment 2843 [details]
update; cleaned up some things
Comment 9 Aaron Schulz 2006-12-09 05:16:08 UTC
Created attachment 2844 [details]
upate; clean up form
Comment 10 Aaron Schulz 2006-12-12 23:20:10 UTC
Created attachment 2852 [details]
Summary patch for checkuser (see http://www.mediawiki.org/wiki/User:Voice_of_All/CheckUser2.0)
Comment 11 Aaron Schulz 2006-12-13 02:58:34 UTC
Created attachment 2854 [details]
Summary patch; pretty up form and fixed two small bugs
Comment 12 Brion Vibber 2006-12-14 22:10:10 UTC
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

Comment 13 Aaron Schulz 2006-12-15 01:52:58 UTC
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.
Comment 14 Aaron Schulz 2006-12-15 01:56:17 UTC
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.
Comment 15 Brion Vibber 2006-12-15 09:29:34 UTC
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? :)
Comment 16 Brion Vibber 2006-12-15 09:35:02 UTC
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.
Comment 17 Aaron Schulz 2006-12-15 19:06:10 UTC
Created attachment 2870 [details]
update summary patch; XHTML valid, and script title fixed
Comment 18 Aaron Schulz 2006-12-15 19:06:48 UTC
(The other fixes are included in the last patch as well)
Comment 19 Brion Vibber 2006-12-16 01:47:43 UTC
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.
Comment 20 Brion Vibber 2006-12-16 01:48:09 UTC
Most of the other problems seem fixed, though. Good job!

Sorry, didn't want to be all negative there. ;)
Comment 21 Aaron Schulz 2006-12-16 09:30:58 UTC
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 :).
Comment 22 Aaron Schulz 2006-12-16 09:36:21 UTC
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.
Comment 23 Rob Church 2006-12-16 09:57:45 UTC
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?
Comment 24 Aaron Schulz 2006-12-16 19:16:05 UTC
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.
Comment 25 Brion Vibber 2006-12-18 22:47:12 UTC
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.
Comment 26 Aaron Schulz 2006-12-19 08:10:29 UTC
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 :) ...
Comment 27 Aaron Schulz 2006-12-19 08:11:52 UTC
Oh, and "get edits", no says "get edits (default)". The enter hacks didn't
require a separate reason box fortunetely.
Comment 28 Aaron Schulz 2006-12-19 08:22:39 UTC
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).
Comment 29 Brion Vibber 2006-12-24 09:10:29 UTC
Applied on r18552.
Comment 30 Aaron Schulz 2006-12-25 02:12:52 UTC
Created attachment 2944 [details]
Improve hack for "enter" key

More predictable behavoir when not using enter
Comment 31 Aaron Schulz 2006-12-25 02:40:28 UTC
Created attachment 2945 [details]
Improve hack for "enter" key

Diff against svn hopefully

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


Navigation
Links