Last modified: 2011-11-25 08:36:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18814, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16814 - Require active confirmation when Re-blocking a user
Require active confirmation when Re-blocking a user
Status: NEW
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-27 20:21 UTC by Church of emacs
Modified: 2011-11-25 08:36 UTC (History)
5 users (show)

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


Attachments

Description Church of emacs 2008-12-27 20:21:39 UTC
On dewiki many administrators are requesting a change to the process of re-blocking users. It'd be useful to have a checkbox "[ ] confirm re-block" and therefor to require active confirmation when Re-blocking a user. Having a small message "<user> is already blocked. Do you want to change the settings?" and a different text on the submit button "Re-block the user with these settings" is not sufficient, as most administrators don't read the whole text when they block.

Re-blocking without consensus or agreement of the blocking administrator is often regarded as rude on dewiki, therefor most administrators wish to avoid re-blocks by accident.

Consensus on this bugreport on the Administrators'_noticeboard:
http://de.wikipedia.org/wiki/Wikipedia:Administratoren/Notizen#Verl.C3.A4ngerung.2FVerk.C3.BCrzung_von_Sperren_.232
Comment 1 Mike.lifeguard 2008-12-28 05:56:53 UTC
(In reply to comment #0)
> On dewiki many administrators are requesting a change to the process of
> re-blocking users. It'd be useful to have a checkbox "[ ] confirm re-block" and
> therefor to require active confirmation when Re-blocking a user. Having a small
> message "<user> is already blocked. Do you want to change the settings?" and a
> different text on the submit button "Re-block the user with these settings" is
> not sufficient, as most administrators don't read the whole text when they
> block.
> 
> Re-blocking without consensus or agreement of the blocking administrator is
> often regarded as rude on dewiki, therefor most administrators wish to avoid
> re-blocks by accident.
> 
> Consensus on this bugreport on the Administrators'_noticeboard:
> http://de.wikipedia.org/wiki/Wikipedia:Administratoren/Notizen#Verl.C3.A4ngerung.2FVerk.C3.BCrzung_von_Sperren_.232
> 

This was the case until recently. There was a checkbox (unchecked by default, IIRC) which one had to check off to change block settings. I don't know what the problem was with that - it seemed perfectly sensible to me that
1) You would require active confirmation for something like that and
2) You would use a checkbox in exactly that manner to do it

So, probably it is a simple revert of whatever commit changed that.
Comment 2 Aaron Schulz 2009-01-02 20:03:55 UTC
When I go to block a blocked user I get a 'Already blocked' message and the submit button says "reblock this user".

Is a checkbox really needed here?
Comment 3 Mike.lifeguard 2009-01-02 21:07:35 UTC
(In reply to comment #2)
> When I go to block a blocked user I get a 'Already blocked' message and the
> submit button says "reblock this user".
> 
> Is a checkbox really needed here?
> 

Well, we want some sort of /active/ confirmation - not just notification. Whether it's a checkbox or something else (dunno what it could be) is immaterial.
Comment 4 Mike.lifeguard 2009-01-14 15:33:00 UTC
Just like moving a page to a location where a page already exists - a checkbox to confirm that you want to delete the page is shown.
Comment 5 mnh 2009-07-15 22:26:01 UTC
There's a similiar problem (with the same solution) in 
case a sysop for whatever reason reuses a pre-filled
open block dialog to issue another block. 

Steps to reproduce:

 - open Special:Block/BlockedVillain
 - change victim
 - Press enter
 
This may seem constructed, but it actually happens. Opening
the first dialog fills every required field, pressing enter
on name change (maybe out of habit) triggers the block.

I'm somewhat unhappy with that from a usability perspective.
Changing the name is possible, it's therefore perfectly valid
user input. The blocking sysop is however unlikely to want
the exact same block on the newly entered account and may
thus feel the block triggered too early. (Which is what
actually happened to a fellow sysop.)

Any kind of active confirmation when using an already filled
form would solve this.

Cheers, --mnh

Comment 6 John Mark Vandenberg 2011-04-28 15:05:50 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > On dewiki many administrators are requesting a change to the process of
> > re-blocking users. It'd be useful to have a checkbox "[ ] confirm re-block" and
> > therefor to require active confirmation when Re-blocking a user. Having a small
> > message "<user> is already blocked. Do you want to change the settings?" and a
> > different text on the submit button "Re-block the user with these settings" is
> > not sufficient, as most administrators don't read the whole text when they
> > block.
> > 
> > Re-blocking without consensus or agreement of the blocking administrator is
> > often regarded as rude on dewiki, therefor most administrators wish to avoid
> > re-blocks by accident.
> > 
> > Consensus on this bugreport on the Administrators'_noticeboard:
> > http://de.wikipedia.org/wiki/Wikipedia:Administratoren/Notizen#Verl.C3.A4ngerung.2FVerk.C3.BCrzung_von_Sperren_.232
> > 
> 
> This was the case until recently. There was a checkbox (unchecked by default,
> IIRC) which one had to check off to change block settings. I don't know what
> the problem was with that - it seemed perfectly sensible to me that
> 1) You would require active confirmation for something like that and
> 2) You would use a checkbox in exactly that manner to do it
> 
> So, probably it is a simple revert of whatever commit changed that.

r43870?

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


Navigation
Links