Last modified: 2007-06-02 00:06:02 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.
I doubt this is currently stored in the block logs . . . is it?
(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?
(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.
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.
(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.
(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.
(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.
