| • bzimport | |
| May 31 2007, 7:21 AM |
| F4170: diff.patch | |
| Nov 21 2014, 9:52 PM |
Author: falkeli
Description:
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.
Version: unspecified
Severity: enhancement
ayg wrote:
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.
fearow00 wrote:
If it is fixed, not many people know about it. Almost always, on enwiki, people unblock then reblock, which looks unusual.
ayg wrote:
(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.
thomas.dalton wrote:
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.
Created attachment 4742
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.
attachment 10080block.patch ignored as obsolete
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
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.
Attached:
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: