Page MenuHomePhabricator

Special:Block options should be enable/disable, and not hide/show
Closed, ResolvedPublic1 Story Points

Description

Problem

Special:Block has an outdated UI behavior where some checkboxes will hide/show based on the configuration of the block. Current Wikimedia interface design standards dictate these options should be enable/disabled.


Solution

Where the checkbox is never visible to a particular admin because they don't have the correct permissions, it should remain never visible to them.

Where a checkbox can be visible to an admin if they enter certain parameters, it should go between enabled/disabled instead of shown and hidden. (It should probably also be appropriately checked if disabled, so that the admin can understand what the block will do.)


Acceptance criteria

  • The Automatically block the last IP address used by this user, [...] checkbox behavior should be changed from hide/show to enable/disable
  • The Hide this username checkbox behavior should be changed from hide/show to enable/disable
  • No defaults or behaviors should change other than the aforementioned UI changes.
    • e.g. the Hide this username should only appear to users with the appropriate permissions
    • e.g. the Automatically block the last IP should only be enabled if a username is provided

Event Timeline

dmaza created this task.Dec 20 2018, 3:53 AM
Restricted Application added subscribers: MGChecker, Aklapper. ยท View Herald TranscriptDec 20 2018, 3:53 AM
JJMC89 added a subscriber: JJMC89.

! @dmaza wrote:
Prevent account creation is of no use if the target of the block is an already existing user

It prevents the blocked user from creating a new account after being blocked.

dmaza added a comment.Dec 20 2018, 4:30 AM

@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.

But, it would make sense to enable it if an admin checks Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from

@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.

Yes, you can. (I do it all the time.)

dmaza added a comment.Dec 20 2018, 4:45 AM

@JJMC89 Unless I'm missing something, you can't create an account if you are already signed in.

Yes, you can. (I do it all the time.)

Look at that.. I had no idea. Thanks for correcting me.

Recycling this ticket for a different option.

dmaza renamed this task from Special:Block prevent account creation should be disabled if the target is a username to Special:Block option "Automatically block the last IP..." should be disabled and not hidden when applies.Dec 20 2018, 4:46 AM
dmaza updated the task description. (Show Details)
TBolliger triaged this task as Low priority.Dec 20 2018, 5:13 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.
TBolliger renamed this task from Special:Block option "Automatically block the last IP..." should be disabled and not hidden when applies to Special:Block option "Automatically block the last IP..." interaction should be enable/disable, and not hide/show.Jan 30 2019, 10:14 PM
TBolliger renamed this task from Special:Block option "Automatically block the last IP..." interaction should be enable/disable, and not hide/show to Special:Block options should be enable/disable, and not hide/show.Feb 21 2019, 7:32 PM
TBolliger updated the task description. (Show Details)
TBolliger updated the task description. (Show Details)
TBolliger set the point value for this task to 1.

Here's what we discussed in estimation:

Where the checkbox is never visible to a particular admin because they don't have the correct permissions, it should remain never visible to them.

Where a checkbox can be visible to an admin if they enter certain parameters, it should go between enabled/disabled instead of shown and hidden. (It should probably also be appropriately checked if disabled, so that the admin can understand what the block will do.)

Here's what we discussed in estimation:
Where the checkbox is never visible to a particular admin because they don't have the correct permissions, it should remain never visible to them.
Where a checkbox can be visible to an admin if they enter certain parameters, it should go between enabled/disabled instead of shown and hidden. (It should probably also be appropriately checked if disabled, so that the admin can understand what the block will do.)

Haha, reading my in-the-meeting notes on this ticket, I realize I was either speaking in tongues or creating a new type of poetry. ๐Ÿ™ƒ

Thanks for clarifying. I'll update/plagiarize the task description with this comment.

TBolliger updated the task description. (Show Details)Feb 22 2019, 4:53 PM
Tchanders moved this task from Ready to In Progress on the Anti-Harassment (Zayin - ื–) board.
Tchanders added a comment.EditedApr 2 2019, 2:11 PM

For testing (and reviewing), here's how everything behaves before the fix:

name in codewidget textshown iff...
enableAutoblockAutomatically block the last IP address used by this user, and any subsequent IP addresses they try to editTarget is NOT an IP/IP range
hideUserHide username from edits and listsTarget is NOT an IP/IP range AND expiry is indefinite AND editing checkbox is checked AND sitewide radio is selected
watchUserWatch this user's user and talk pagesTarget is NOT an IP range
anonOnlyPrevent logged-in users from editing from this IP addressTarget is an IP/IP range/empty

After the fix, we want these to be disabled when they were previously hidden, and enabled when they were previously shown.

Known issues, to be filed and solved separately:

  • While typing in an IP range, after typing '/' but before typing any more numbers, the string is not considered and IP or an IP range, so some of the widgets flicker.
  • The enableAutoblock widget is selected by default. Before the fix, it is still selected when hidden, and still therefore selected when it reappears. (The PHP knows to ignore it if the target is not of the correct type.) After the fix, it should not be selected when disabled, since this misleadingly implies that autoblocks will be enabled. However, when it is re-enabled it will still be unchecked. If this needs to be fixed, we might need to do something similar to the "Account creation" checkbox (T208510).
  • Same as the previous point for the other 3 widgets, except that they are not selected by default.

Change 500760 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] Enable/disable Special:Block widgets according to block parameters

https://gerrit.wikimedia.org/r/500760

Change 500760 merged by jenkins-bot:
[mediawiki/core@master] Enable/disable Special:Block widgets according to block parameters

https://gerrit.wikimedia.org/r/500760

dom_walden added a subscriber: dom_walden.

Acceptance criteria

  • The Automatically block the last IP address used by this user, [...] checkbox behavior should be changed from hide/show to enable/disable
  • The Hide this username checkbox behavior should be changed from hide/show to enable/disable

These, "Watch this user's user and talk pages" and "Prevent logged-in users from editing from this IP address" are enabled/disabled as Thalia states above (T212391#5077484).

This includes when going to Special:Block/$target where $target is a username, IP or IP range (including IPv6 addresses and ranges).

  • No defaults or behaviors should change other than the aforementioned UI changes.
    • e.g. the Hide this username should only appear to users with the appropriate permissions

Yes. Also true for blockemail permission and the "Block user from sending e-mail" checkbox.

  • e.g. the Automatically block the last IP should only be enabled if a username is provided

Anything that it does not recognise as an IPv4/6 address or range will enable this checkbox (even if the username does not exist).

I also checked that blocks could be submitted and their block parameters appropriately recorded in the database.

  • The enableAutoblock widget is selected by default. Before the fix, it is still selected when hidden, and still therefore selected when it reappears. (The PHP knows to ignore it if the target is not of the correct type.) After the fix, it should not be selected when disabled, since this misleadingly implies that autoblocks will be enabled. However, when it is re-enabled it will still be unchecked. If this needs to be fixed, we might need to do something similar to the "Account creation" checkbox (T208510).

This applies to all the checkboxes. When a checkbox is disabled then re-enable it will be unchecked (regardless of its previous state). Because the form appears to treat a half-entered IP address/range (e.g. "192.168.") as a username, it is difficult to interact with the username input without changing the enabled/disabled states of some of the checkboxes.

dbarratt closed this task as Resolved.Apr 15 2019, 1:52 PM
  • The enableAutoblock widget is selected by default. Before the fix, it is still selected when hidden, and still therefore selected when it reappears. (The PHP knows to ignore it if the target is not of the correct type.) After the fix, it should not be selected when disabled, since this misleadingly implies that autoblocks will be enabled. However, when it is re-enabled it will still be unchecked. If this needs to be fixed, we might need to do something similar to the "Account creation" checkbox (T208510).

This applies to all the checkboxes. [...]

This is being fixed in T221117 - after that, the checkboxes will remember their former state when they are re-enabled.