! @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.

@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

In T212391#4836552, @dmaza wrote:

@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.)

In T212391#4836562, @JJMC89 wrote:

In T212391#4836552, @dmaza wrote:

@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.

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.)

In T212391#4975942, @Tchanders wrote:

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.

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

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

This looks good to me, I realized I forgot to create a task for T219931 so I created one. :)

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

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

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.

In T212391#5077484, @Tchanders wrote:

• 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.

• 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.