ayg wrote:

I doubt this is currently stored in the block logs . . . is it?

cannon.danielc wrote:

(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?

Prodego wrote:

(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.

cannon.danielc wrote:

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.

Attached:

cannon.danielc wrote:

(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.

Prodego wrote:

(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.

cannon.danielc wrote:

(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.