Last modified: 2007-06-02 00:06:02 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 10076 - Make blockIDs searchable in the block log
Make blockIDs searchable in the block log
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-30 21:01 UTC by Prodego
Modified: 2007-06-02 00:06 UTC (History)
1 user (show)

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


Attachments
Provided blocking range in MediaWiki:Blockedtext (795 bytes, patch)
2007-05-31 03:05 UTC, Daniel Cannon (AmiDaniel)
Details

Description Prodego 2007-05-30 21:01:41 UTC
The block ID number assigned to each block provides an instant way to find out what block is affecting a blocked user, regardless of the block level (i.e. you could find a range block affecting a single IP). This is done by prefixing the number with '#' and entering into Special:Ipblocklist. However, the blocklist only shows currently active blocks, and if the block is undone, there is no longer any way to find out any information about the block. It would helpful to be able to search for these in the block log, and since usernames may not start with a #, there should be no incompatibility.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-30 21:52:02 UTC
I doubt this is currently stored in the block logs . . . is it?
Comment 2 Daniel Cannon (AmiDaniel) 2007-05-30 23:49:14 UTC
(In reply to comment #1)
> I doubt this is currently stored in the block logs . . . is it?
> 

Just checked, and, no, it's not in there any where. I also can't think of any logical place this could be placed in the logging table that would be grepable (It could be stuck in params, but this isn't at all grepable). Only thing that comes to mind is possibly storing a log entry with log_title = ipb_id for each block and autoblock, but this seems quite disgusting to me. I also wonder how useful it would be -- block ids disappear once the block is lifted, although they don't appear to be recycled. What real use is the ability to search for expired blocks by id?
Comment 3 Prodego 2007-05-31 01:30:39 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I doubt this is currently stored in the block logs . . . is it?
> > 
> 
> Just checked, and, no, it's not in there any where. I also can't think of any
> logical place this could be placed in the logging table that would be grepable
> (It could be stuck in params, but this isn't at all grepable). Only thing that
> comes to mind is possibly storing a log entry with log_title = ipb_id for each
> block and autoblock, but this seems quite disgusting to me. I also wonder how
> useful it would be -- block ids disappear once the block is lifted, although
> they don't appear to be recycled. What real use is the ability to search for
> expired blocks by id?
> 


Currently the only (ok, *best*) way to discover what range block is affecting a user in a blocked range is through the block ID. However, if the block is undone, there is no way for someone else to find out what the block was on. This is a minor, minor, wishlist thing. If it is not possible it isn't a big thing, perhaps in the future it will be.
Comment 4 Daniel Cannon (AmiDaniel) 2007-05-31 03:05:45 UTC
Created attachment 3697 [details]
Provided blocking range in MediaWiki:Blockedtext

Will this do what you want? If the user is blocked as the result of a range block, this will provide the range as parameter $7 in MediaWiki:Blockedtext. If it's not a range block, $7 will be an empty string. The range itself is quite easily grepable in the logs, so if all you're concerned with are rangeblocks, this should do what you need.
Comment 5 Daniel Cannon (AmiDaniel) 2007-06-01 07:59:25 UTC
(In reply to comment #4)
> Created an attachment (id=3697) [details]
> Provided blocking range in MediaWiki:Blockedtext

Went ahead and committed as r22623. Waiting on input from Prodego to see if we can go ahead and close this bug.

Comment 6 Prodego 2007-06-01 15:38:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Created an attachment (id=3697) [details] [details]
> > Provided blocking range in MediaWiki:Blockedtext
> 
> Went ahead and committed as r22623. Waiting on input from Prodego to see if we
> can go ahead and close this bug.
> 

Looks good, but a suggestion:

Sometimes it is hard to know exactly what is blocking an account. It could be a rangeblock, an IP block, an account block, an autoblock... While autoblocks are easily identified, it might be helpful to have some why to identify what is actually causing the block. The block ID will tell you this indirectly, but if there were a field that could give you not just range for rangeblocks, but the CIDR notation of the block (i.e. 127.0.0.0/16) IP for range blocks (more user friendly), or whether the IP is blocked or the user is blocked, that would be nice. However, rangeblocks are the hardest to find, and thus the biggest problem, so your change is a great improvement.
Comment 7 Daniel Cannon (AmiDaniel) 2007-06-02 00:06:02 UTC
(In reply to comment #6)
> actually causing the block. The block ID will tell you this indirectly, but if
> there were a field that could give you not just range for rangeblocks, but the
> CIDR notation of the block (i.e. 127.0.0.0/16) IP for range blocks (more user
> friendly), or whether the IP is blocked or the user is blocked, that would be
> nice. However, rangeblocks are the hardest to find, and thus the biggest
> problem, so your change is a great improvement.
> 

Well, why didn't you say so :P. This is actually easier to do; just output whoever the heck the blockee is in $7. Committed as r22641. Also closing bug.

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


Navigation
Links