Last modified: 2008-10-30 21:47:14 UTC
Currently, in order to change a block (duration, whether or not it affects registered users, etc.), an admin must first unblock the account, then reblock it. The result is that there are more lines in the user's block log, which is a small issue; however, it also means that the user is unblocked for some time, and if the admin gets disconnected before finishing the re-block - the user can cause a lot of damage this way.
What happens if you just block again without unblocking in the interim? It used to be that there would be strangeness with the block expiration, but I thought that was fixed.
*** Bug 10673 has been marked as a duplicate of this bug. ***
If it is fixed, not many people know about it. Almost always, on enwiki, people unblock then reblock, which looks unusual.
(In reply to comment #1) > What happens if you just block again without unblocking in the interim? Apparently, you get told "'Username' is already blocked", and nothing happens. Yes, this is fairly ridiculous, and fairly trivial to fix.
Some kind of confirmation page would be good, rather than just overwriting the previous block, since it's not unusual for two admins to go to block to the same user and the same time and trip up over each other.
(In reply to comment #5) > since it's not unusual for two admins to go to block to the > same user and the same time and trip up over each other. At present, that's not even possible: you can't block a user twice.
Well, yes, the 2nd one gets an error message.
Created attachment 4742 [details] Priliminary (test) patch for this bug I created a preliminary patch for this bug. It does the unblock-reblock stuff automatically, and also loads the expiration time of the currently active block, to let the admin modify other options without touching the block duration. It works in the very few tests I made, however, I'm not 100% sure of how it is dealing with block options (I've this bad feeling that it is mixing the options coming from a user block with those coming from the associated autoblock). It would be great if someone could test it and leave comments.
I put this patch on my local install. Works well, allows the end-user to easily reblock without unblocking. However, entering a log entry for the unblock seems rather useless. I'll play with it and see if we can do this without having to add that dummy entry.
Fixed in r35901. Made a minor tweak to make it silently unblock, so we don't have a cluttered log for a simple adjustment of block expiry.
Created attachment 4962 [details] Updated patch Here's my updated patch. Fixed the UI errors, but still having issues with rangeblocks (sees an IP within range as already blocked, cool, but not intended). Removed in r35977 until we figure out why.
Fixed correctly as of r36076.
Reverted as it's still not working correctly. Often comes up with the "wrong" conflicting block, sometimes removing range blocks or failing to modify the correct block depending on which tweaked version. Would be best to find an exact match and work with it by block id, probably, rather than this general 'remove and replace' which seems so fragile. Need to consider that there may be side-by-side: * range blocks * individual IP blocks * individual IP blocks applying to anons only * auto blocks
Done in r42843.
