Last modified: 2008-10-30 21:47:14 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 10080 - Allow modification of a block without unblocking
Allow modification of a block without unblocking
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Chad H.
: easy, patch, patch-need-review
: 10673 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-31 07:21 UTC by (none)
Modified: 2008-10-30 21:47 UTC (History)
7 users (show)

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


Attachments
Priliminary (test) patch for this bug (3.72 KB, patch)
2008-03-21 10:55 UTC, Huji
Details
Updated patch (3.17 KB, patch)
2008-06-06 18:39 UTC, Chad H.
Details

Description (none) 2007-05-31 07:21:58 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-31 16:57:27 UTC
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.
Comment 2 Rob Church 2007-07-24 08:30:46 UTC
*** Bug 10673 has been marked as a duplicate of this bug. ***
Comment 3 Matt 2007-07-24 08:39:36 UTC
If it is fixed, not many people know about it. Almost always, on enwiki, people unblock then reblock, which looks unusual.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-24 18:09:48 UTC
(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.
Comment 5 Thomas "Tango" Dalton 2007-09-12 13:23:40 UTC
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.
Comment 6 Roan Kattouw 2007-09-12 14:35:08 UTC
(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.
Comment 7 Thomas "Tango" Dalton 2007-09-12 14:43:17 UTC
Well, yes, the 2nd one gets an error message.
Comment 8 Huji 2008-03-21 10:55:22 UTC
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.
Comment 9 Chad H. 2008-06-04 22:53:09 UTC
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.
Comment 10 Chad H. 2008-06-05 00:11:40 UTC
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.
Comment 11 Chad H. 2008-06-06 18:39:46 UTC
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.
Comment 12 Chad H. 2008-06-09 13:06:06 UTC
Fixed correctly as of r36076. 
Comment 13 Brion Vibber 2008-06-09 23:19:27 UTC
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
Comment 14 Alex Z. 2008-10-30 21:47:14 UTC
Done in r42843.

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


Navigation
Links