@Tks4Fish are you still working on this?

With the introduction of Temporary accounts, this now becomes more important. Having Special:MassGlobalBlock would allow Stewards to easily block Temporary accounts created by a LTA (example).

Do we need a new special page, or would it be possible to add the functionality into the existing Special:GlobalBlock page?

In T124607#10359476, @kostajh wrote:

Do we need a new special page, or would it be possible to add the functionality into the existing Special:GlobalBlock page?

I don't think it will be easy to combine it into the existing Special:GlobalBlock page because the target input would need to be converted from a single user target input to a textarea. With other changes, we would in a sense be making Special:GlobalBlock into Special:MassGlobalBlock and loose some features (such as loading the existing block options as the default for the form).

Furthermore, depending on how the form is built, we might be adding a prefix search user lookup (i.e. "search for users which begin with this text") so that a steward could globally block accounts created in a specific pattern. I've asked to see if this feature is useful. If we do add it, the MassGlobalBlock page would have to be a two step form (so that confirmation on which accounts to be globally blocked could be made).

Perhaps it could start similar to how Special:MultiLock works?

As a MVP, I'd want to be able to input multiple newline delimited targets e.g.

10.0.0.1
10.0.0.2
10.1.0.0/24
10.128.0.0/16

In T124607#10361054, @Xaosflux wrote:

Perhaps it could start similar to how Special:MultiLock works?

As a MVP, I'd want to be able to input multiple newline delimited targets e.g.

10.0.0.1
10.0.0.2
10.1.0.0/24
10.128.0.0/16

Thanks for your feedback.

Would you also like to see the "search for usernames with a prefix" feature present on the special page (that is present on Special:MultiLock)?

Could be useful, but so long as I could dump in a list of names to the input box that would be a good start.

Change #1099068 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Add Special:MultiBlock

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

Change #829290 abandoned by Dreamy Jazz:

[mediawiki/extensions/GlobalBlocking@master] Add Special:MultiBlock

Reason:

Git-review seems to have re-created this as a different patch - https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalBlocking/+/1099068

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

Change #1099068 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Add Special:MultiBlock

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

Change #1099180 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Add GlobalBlockingExpirySelectorBuilder service

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

Change #1099181 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Simplify GlobalBlockingExpirySelectorBuilder::buildExpirySelector

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

Change #1099182 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Prevent Special:GlobalBlock 'hide-if' fields flashing on page load

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

Change #1099183 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Make GlobalBlockManager::block not modify global autoblocks

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

Change #1099191 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] Add navigation link to Special:MassGlobalBlock

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

Change #1099202 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] [WIP] Add Special:MassGlobalBlock

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

Change #1099180 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Add GlobalBlockingExpirySelectorBuilder service

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

Change #1099181 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Simplify GlobalBlockingExpirySelectorBuilder::buildExpirySelector

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

Change #1099182 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Prevent Special:GlobalBlock 'hide-if' fields flashing on page load

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

Change #1099183 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Make GlobalBlockManager::block not modify global autoblocks

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

Change #1100150 had a related patch set uploaded (by Tchanders; author: Tchanders):

[operations/mediawiki-config@master] Ensure IP reveal buttons are not shown on Special:MassGlobalBlock

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

Change #1099202 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Add Special:MassGlobalBlock

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

Change #1100150 merged by jenkins-bot:

[operations/mediawiki-config@master] Ensure IP reveal buttons are not shown on Special:MassGlobalBlock

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

Mentioned in SAL (#wikimedia-operations) [2024-12-04T13:47:01Z] <dreamyjazz@deploy2002> Started scap sync-world: Backport for [[gerrit:1100150|Ensure IP reveal buttons are not shown on Special:MassGlobalBlock (T124607)]]

Mentioned in SAL (#wikimedia-operations) [2024-12-04T13:53:10Z] <dreamyjazz@deploy2002> tchanders, dreamyjazz: Backport for [[gerrit:1100150|Ensure IP reveal buttons are not shown on Special:MassGlobalBlock (T124607)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-12-04T14:00:10Z] <dreamyjazz@deploy2002> Finished scap sync-world: Backport for [[gerrit:1100150|Ensure IP reveal buttons are not shown on Special:MassGlobalBlock (T124607)]] (duration: 13m 08s)

Change #1099068 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Add blocking functionality to Special:MassGlobalBlock

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

Change #1099191 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Add navigation link to Special:MassGlobalBlock

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

Moving to 'Needs Design Review' so that design can take a look at this. We have now implemented the Special:MassGlobalBlock page and I've made an example of how a user would use the special page:

To globally block:

Query form (step 1)	Query form (step 2)	Block form (step 2)	Block form (step 3)
What a user sees when they load the page	A user enters the targets they want to globally block or unblock into the text field separating each target by a new line	The user reviews the table of targets they entered, including seeing the existing global blocks	The user selects the targets they want to globally block, sets the options, and presses submit to perform the blocking

To globally unblock:

Query form (step 1)	Query form (step 2)	Block form (step 2)	Block form (step 3)
What a user sees when they load the page	A user enters the targets they want to globally block or unblock into the text field separating each target by a new line	The user reviews the table of targets they entered, including seeing the existing global blocks and selects the radio option to globally unblock	The user selects the targets, gives a reason, and presses submit to perform the unblocking (in this example the IP was already unblocked which causes the error message)

I see that TestUsername is showing up as invalid. Is that because there is no such user or because named accounts can't be mass blocked? The latter should be possible.

I'm not sure that accepting block IDs makes sense. You can't create blocks from an ID, only modify and unblock. I can't think of a use case of mass action where you wouldn't use the target username/IP.

I assume that the of the block options selected on the form, only those that apply to the target type are actually applied. e.g., autoblocks are not attempting to be set for IP (range) blocks and anon-only not for account blocks.

In T124607#10384841, @JJMC89 wrote:

I see that TestUsername is showing up as invalid. Is that because there is no such user or because named accounts can't be mass blocked? The latter should be possible.

This is because there is no such username. I should have made that clearer. You are able to use this form to globally block any target you can globally block using Special:GlobalBlock. The error message shown there is the same one used by Special:GlobalBlock when the username doesn't exist (which maybe should be made clearer).

I'm not sure that accepting block IDs makes sense. You can't create blocks from an ID, only modify and unblock. I can't think of a use case of mass action where you wouldn't use the target username/IP.

Accepting global block IDs is so that a steward can remove global autoblocks using this form. Otherwise they would have needed to use Special:RemoveGlobalBlock to do that one at a time.

I assume that the of the block options selected on the form, only those that apply to the target type are actually applied. e.g., autoblocks are not attempting to be set for IP (range) blocks and anon-only not for account blocks.

Yes.

Thanks for sharing this @Dreamy_Jazz

The user flow looks good. I compared this with the new multi-block design for Special:Block and have some suggestions to closer align the pages:

• Grouping radio buttons and checkboxes under headings
• Copy tweaks for consistency

Search form

Global block form

Global unblock form

Questions I have:

1. What fields are optional?
2. Is it possible to add a select all checkbox to the table (assuming that is useful)?
3. Can inline errors in the selected targets table be styled as errors?
4. For unblocking: Is it possible to show an inline error message within the targets table, so that if a user selects a target to unblock which has no global block on, it will display an inline error, rather than displaying an error message on the page after submitting?

In T124607#10413843, @KColeman-WMF wrote:

Global block form

Component/field	Current copy	Suggested copy
Form fieldset title	Globally block or unblock multiple targets	Selected targets
Inline error	The username, IP address, or IP range (TestUsername) you entered is invalid	“TestUsername” is invalid
Radio group label		Global block type
Radio buttons	Globally block selected targets, Globally unblock selected targets	Block, Unblock
Checkbox group label		Global block details
Checkboxes	Globally block anonymous users only, Globally disable account creation	Anonymous users only, Account creation
Checkbox group label		Additional details
Checkboxes	Automatically globally block the last IP address used by this user, and any subsequent IP addresses they try to edit from, for a period of 1 day	Globally block the last IP address used by this account, and any subsequent IP addresses they try to edit from, for one day
Button	Submit	Add global block

Three clarification questions about this:

1. The 'Global block details' section is where I would place the 'Globally block the last IP address ...' field because this is a setting of the global block and is shown in Special:GlobalBlockList in the same way that the Account creation and Anonymous users only fields. Therefore, could this field be placed there?
2. The invalid username error is the same text as is used on the Special:GlobalBlock page when the target entered is invalid. See the screenshot below for this. Updating this text would also update the text for the Special:GlobalBlock page. Is this okay?

3. The form can be used to both modify and add global blocks. Therefore, I'm not sure if the submit button text fits this because it's not currently plural and reads to me that this only adds global blocks (not modifies them). The multi-blocks design has a different wording for the submit button when modifying a global block. Given that a user could be modifying and placing global blocks in the same use of the form, might I suggest a submit button text that is agnostic to whether the global blocks are being added or modified.
4. The reason field layout has changed such that the textbox for the other reason is placed next to the dropdown menu. Is this intended? I placed the dropdown deliberately above the reason field because the options that appear there are frequently long. For example, on Special:Block the options to select from the dropdown take up the entire screen when opened. If the dropdown menu selector is short like this then the pre-filled reasons will be nearly always cut off:

5. Is the removal of the "other" textbox for the expiry field deliberate?

Questions I have:

1. What fields are optional?

The targets field on the search form is required, as to is the expiry field when globally blocking. All other fields are not required (at this point in time).

1. Is it possible to add a select all checkbox to the table (assuming that is useful)?

I'm not sure of this use case, because the fields are by default all checked. We could add the ability to select all, none or invert the selection using the same feature used by Special:CheckUser shown in the screenshot below:

1. Can inline errors in the selected targets table be styled as errors?

It should be technically possible to style them as errors.

1. For unblocking: Is it possible to show an inline error message within the targets table, so that if a user selects a target to unblock which has no global block on, it will display an inline error, rather than displaying an error message on the page after submitting?

I'm not sure how the design would work for this because I could see it being very confusing if all the global unblocks fail on a list of 50 targets. For example, this could occur if a user is globally unblocking just as the site goes into read only mode. However, from a technical point of view it should be possible.

Also, do the following messages also need updating? These messages also appear at Special:GlobalBlock in the same way as the invalid target message:

Three clarification questions about this:

1. The 'Global block details' section is where I would place the 'Globally block the last IP address ...' field because this is a setting of the global block and is shown in Special:GlobalBlockList in the same way that the Account creation and Anonymous users only fields. Therefore, could this field be placed there?

Yes we can do that, I was following Special:Block but what you suggest makes sense to me.

2. The invalid username error is the same text as is used on the Special:GlobalBlock page when the target entered is invalid. See the screenshot below for this. Updating this text would also update the text for the Special:GlobalBlock page. Is this okay?

Yes, we can make both pages consistent with UX copywriting guidance. Ideally we would provide a reason why it's invalid too.

3. The form can be used to both modify and add global blocks. Therefore, I'm not sure if the submit button text fits this because it's not currently plural and reads to me that this only adds global blocks (not modifies them). The multi-blocks design has a different wording for the submit button when modifying a global block. Given that a user could be modifying and placing global blocks in the same use of the form, might I suggest a submit button text that is agnostic to whether the global blocks are being added or modified.

Ah I see, thanks for clarifying that! I hope that eventually we'll build this like Special:Block but until that time, let's use 'Submit' as suggested.

4. The reason field layout has changed such that the textbox for the other reason is placed next to the dropdown menu. Is this intended? I placed the dropdown deliberately above the reason field because the options that appear there are frequently long. For example, on Special:Block the options to select from the dropdown take up the entire screen when opened. If the dropdown menu selector is short like this then the pre-filled reasons will be nearly always cut off:

In the multi-block design the select menu and reason text field are side-by-side and it looks like the reasons are all of sensible length (perhaps these have been re-written?) Let's go with your suggestion and keep the reason field underneath. Although I would be interested to understand how/where those pre-filled suggestions are written (multi-block has a link to edit them).

5. Is the removal of the "other" textbox for the expiry field deliberate?

No, that should remain.

1. Is it possible to add a select all checkbox to the table (assuming that is useful)?

I'm not sure of this use case, because the fields are by default all checked. We could add the ability to select all, none or invert the selection using the same feature used by Special:CheckUser shown in the screenshot below:

It sounds like there isn't a use case for this, so we can keep the table as it is.

1. Can inline errors in the selected targets table be styled as errors?

It should be technically possible to style them as errors.

Great, that would be good if possible!

1. For unblocking: Is it possible to show an inline error message within the targets table, so that if a user selects a target to unblock which has no global block on, it will display an inline error, rather than displaying an error message on the page after submitting?

I'm not sure how the design would work for this because I could see it being very confusing if all the global unblocks fail on a list of 50 targets. For example, this could occur if a user is globally unblocking just as the site goes into read only mode. However, from a technical point of view it should be possible.

Hm, you make a good point. I will have a think about that one.

Also, do the following messages also need updating? These messages also appear at Special:GlobalBlock in the same way as the invalid target message:

Yes, I can rewrite these messages in line with copywriting guidance.

@Dreamy_Jazz For inline error messages in the table, is it possible to display them underneath the query that was inputted?

This would then be consistent with how Codex inline errors display, and also mean that we can avoid showing "really-long-names-like-IPv6-range" as part of the error text.

If we can do this then the errors would display as follows:

In T124607#10415282, @KColeman-WMF wrote:

4. The reason field layout has changed such that the textbox for the other reason is placed next to the dropdown menu. Is this intended? I placed the dropdown deliberately above the reason field because the options that appear there are frequently long. For example, on Special:Block the options to select from the dropdown take up the entire screen when opened. If the dropdown menu selector is short like this then the pre-filled reasons will be nearly always cut off:

In the multi-block design the select menu and reason text field are side-by-side and it looks like the reasons are all of sensible length (perhaps these have been re-written?) Let's go with your suggestion and keep the reason field underneath. Although I would be interested to understand how/where those pre-filled suggestions are written (multi-block has a link to edit them).

The pre-filled suggestions for the Special:MassGlobalBlock page come from the MediaWiki:Globalblocking-block-reason-dropdown page (which is this for WMF wikis).

Special:Block already uses MediaWiki:Ipbreason-dropdown, so this pre-dates the Multi-Blocks work. For example, the page on metawiki has the reasons customised and also long because of the URLs in the links.

In T124607#10417100, @KColeman-WMF wrote:

@Dreamy_Jazz For inline error messages in the table, is it possible to display them underneath the query that was inputted?

This would then be consistent with how Codex inline errors display, and also mean that we can avoid showing "really-long-names-like-IPv6-range" as part of the error text.

If we can do this then the errors would display as follows:

I think it would be possible to do this.

In T124607#10429446, @Dreamy_Jazz wrote:

In T124607#10417100, @KColeman-WMF wrote:

@Dreamy_Jazz For inline error messages in the table, is it possible to display them underneath the query that was inputted?

This would then be consistent with how Codex inline errors display, and also mean that we can avoid showing "really-long-names-like-IPv6-range" as part of the error text.

If we can do this then the errors would display as follows:

I think it would be possible to do this.

Thank you @Dreamy_Jazz.

@Dreamy_Jazz Here are the finalised suggestions based on our previous discussions:

Search form

Global block form

Global unblock form

Error messages

In T124607#10436962, @KColeman-WMF wrote:

@Dreamy_Jazz Here are the finalised suggestions based on our previous discussions:

We had previously discussed that we would not change the submit button text due to the form being able to remove and add global blocks in T124607#10415282. Has that changed?

If we want to change the submit button text it should be possible, but the text would need to change when a user selects a different radio option so would add additional complication.

In T124607#10436962, @KColeman-WMF wrote:

@Dreamy_Jazz Here are the finalised suggestions based on our previous discussions:

Search form

Component/field	Old copy	New copy
Page description	You can use this page to block multiple users and/op IP addresses on all wikis.	Block or unblock multiple users on all wikis.
Form fieldset title	Query targets to globally block or unblock	Targets
Placeholder	Enter one or more IP addresses, IP ranges, accounts, or global block IDs. Each should be separated by a new-line.	Enter one or more username, IP address, IP range, or global block ID. Each target should be on a new line.

Should we style the search form as being marked as required using the OOUI format? Currently the OOUI form field has the star on the top right hand side to indicate that it is required:

@Dreamy_Jazz wrote:
We had previously discussed that we would not change the submit button text due to the form being able to remove and add global blocks in T124607#10415282. Has that changed?

If we want to change the submit button text it should be possible, but the text would need to change when a user selects a different radio option so would add additional complication.

I may have misunderstood, as I thought the issue was having a button that said "Add global block" when a user can in fact add or modify a global block. If it's not too much work to have the button change to say "Remove global block" when the "unblock" radio button is selected than that would be my preference. But equally happy to use "Submit" for both block and unblock if it's too much additional complication.

Should we style the search form as being marked as required using the OOUI format? Currently the OOUI form field has the star on the top right hand side to indicate that it is required:

Yes that makes sense, thanks for spotting it.

In T124607#10437374, @KColeman-WMF wrote:

@Dreamy_Jazz wrote:
We had previously discussed that we would not change the submit button text due to the form being able to remove and add global blocks in T124607#10415282. Has that changed?

If we want to change the submit button text it should be possible, but the text would need to change when a user selects a different radio option so would add additional complication.

I may have misunderstood, as I thought the issue was having a button that said "Add global block" when a user can in fact add or modify a global block. If it's not too much work to have the button change to say "Remove global block" when the "unblock" radio button is selected than that would be my preference. But equally happy to use "Submit" for both block and unblock if it's too much additional complication.

Thanks for the clarification. I'll work on the assumption of adding the changing button text and if that's not feasible / too complicated then I'll just use Submit.

Change #1109674 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/GlobalBlocking@master] [Very WIP] Implement design changes for Special:MassGlobalBlock

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

Just a note for WMF Production metawiki, this page has a collision with the trigger for the gadget ( https://meta.wikimedia.org/wiki/MediaWiki:Gadget-globalmassblock.js ) - anyone wanting to use the new native functionality will need to opt out of that gadget if they were opted in

In T124607#10463816, @Xaosflux wrote:

Just a note for WMF Production metawiki, this page has a collision with the trigger for the gadget ( https://meta.wikimedia.org/wiki/MediaWiki:Gadget-globalmassblock.js ) - anyone wanting to use the new native functionality will need to opt out of that gadget if they were opted in

Thanks for noting this. Should the gadget be marked as deprecated given this? Perhaps some kind of "you can use the new in-built special page" notice displayed when a user uses the gadget?

I put a note on the gadget text for now, and started a discussion at https://meta.wikimedia.org/wiki/MediaWiki_talk:Gadget-globalmassblock.js#Disable%3F -- we should likely just deregister that gadget (as the name is the same it would be a seamless transition for stewards using it)

I've unhooked the gadget trigger for MassGlobalBlock now, if any issues please @ me on the page: https://meta.wikimedia.org/wiki/MediaWiki_talk:Gadget-globalmassblock.js#Disable%3F