Following a conversation with @SPoore and @cwylo about whether it is acceptable to have the block targets in the URL for Special:InvestigateBlock, it was decided that it is acceptable, since check users are already careful not to block user accounts and IP addresses simultaneously when using the multiple blocks tool in Special:CheckUser. They already need to be careful because the history of when blocks were made, and against whom, is already available via the block log.

Change 611398 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Add block form to Special:Investigate

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

In T248530#6295992, @Tchanders wrote:

Following a conversation with @SPoore and @cwylo about whether it is acceptable to have the block targets in the URL for Special:InvestigateBlock, it was decided that it is acceptable, since check users are already careful not to block user accounts and IP addresses simultaneously when using the multiple blocks tool in Special:CheckUser. They already need to be careful because the history of when blocks were made, and against whom, is already available via the block log.

In the end, I opted for using POST instead of passing the targets through the URL, because I realised that we will need to send all of the targets in order to fulfil this criterion:

• The Special:Investigate block will retain the context of the investigation: The multi-select widget will autocomplete for all targets that were in the investigation, even those that weren't selected in the popup.

We may need to do more work in order to fulfill this criterion... It's easy to limit the small widget on Special:Investigate to the targets in the investigation, since that widget can be a TagMultiselectWidget, as specified in the task description. That works because:

• It doesn't need to confirm that the users are valid, because it won't actually be attempting to make any blocks
• A dropdown menu for autocompletion is unnecessary since the targets are all listed above it (and I assume it would be visually undesirable)

@Niharika @Prtksxna @dbarratt For Special:InvestigateBlock we have a dilemma for the target widget:

1. Use a TagMultiselectWidget (or more likely a MenuTagMultiselectWidget, if we want autocompletion), which already has a way to limit the allowed values. However, we'd need to reimplement the validation of users, IPs and IP ranges from UsersMultiselectWidget.
2. Use a UsersMultiselectWidget, which already does the validation we need. However, it's not yet possible to limit the allowed values, so we would need to do that.

(The allowed values should of course be valid users/IPs already, but given that form fields can be manipulated, we need to revalidate.)

My preference is to do (2), since a limited UserMultiselectWidget seems useful, and it avoids a one-time duplication of all the validation code. We could file a follow-up task to this for the UsersMultiselectWidget improvements. That would mean that Special:InvestigateBlock will actually accept any users/IPs (which it currently already does) until that task is completed.

In T248530#6302254, @Tchanders wrote:

In the end, I opted for using POST instead of passing the targets through the URL, because I realised that we will need to send all of the targets in order to fulfil this criterion:

• The Special:Investigate block will retain the context of the investigation: The multi-select widget will autocomplete for all targets that were in the investigation, even those that weren't selected in the popup.

We could also pass the token to Special:InvestigateBlock which would at least be consistent with Special:Investigate (and arguably, a better UX). Though I wonder how valuable this criteria is in the first place?

@Prtksxna

This seems like a lot of extra space (at least on a really wide screen like mine). Why wouldn't it be on the same line as the text?

When the block button is on the same line, does it means that it is taking up horizontal space from the list of users?

When there are lot of users, I don't want the list to take up more vertical space because it is getting lesser width:

No 🙅🏽‍♂️	Yes 🙆🏾‍♂️

@dbarratt, is it possible to have it be on the same line when there are fewer users, and give the list more space when the number of users is higher?

@Prtksxna @dbarratt The position of the buttons/widgets are set via OOUI layouts. To make the design in the task description, it uses a FieldLayout for the widget, then a HorizontalLayout for the buttons, similar to the example at the bottom of this page: https://doc.wikimedia.org/oojs-ui/master/demos/demos.php?page=layouts&theme=wikimediaui&direction=ltr&platform=desktop

The advantage of having all the buttons (block, cancel, continue) in the same layout is that the controls are all in one place, which is helpful when they hide and show.

Another way to solve the gap problem would be to left-align the buttons:

	Few targets	Many targets
Left-align
Right-align

A couple more questions for @Prtksxna :

• I can't find an example of the blue background in OOUI. Is there a standard blue background colour we should use?
• I added the 'destructive' flag to the cancel button, since it makes the form disappear. (Also, since the buttons are items in the horizontal layout, I removed the "or" text in between.) Are those changes OK?

Thanks for the screenshots, @Tchanders. This is really helpful. I think we'll go with the right-aligned option, that is how I had imagined it being. Making it left aligned isn't really giving us any extra space either and putting to many things togeteth.r

I can't find an example of the blue background in OOUI. Is there a standard blue background colour we should use?

This is Accent90 (#eaf3ff) from wikimedia-ui-base. Not sure if its in OOUI or what its called.

I added the 'destructive' flag to the cancel button, since it makes the form disappear

The 'destructive' flag should be used when something is being deleted, not for cancelling out of actions. We (WMF in general) have used it that way in the past though, and that should be corrected.

Also, since the buttons are items in the horizontal layout, I removed the "or" text in between.

👍🏽

Thanks @Prtksxna, we'll make those changes accordingly.

Change 611398 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add block form to Special:Investigate

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

It should be prefilled with all the users that haven't been filtered out...

@Tchanders At the moment, I see it prefilled with all the targets, including filtered out ones. Will this be implemented somewhere else?

On my local, I find the list of targets is narrower than before:

Change 614731 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Filter out excluded targets from Special:Investigate block form

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

At the moment, I see it prefilled with all the targets, including filtered out ones. Will this be implemented somewhere else?

On my local, I find the list of targets is narrower than before

These are both oversights - should be fixed by the above patch. Thanks @dom_walden

Change 614731 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Filter out excluded targets from Special:Investigate block form

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

@Niharika @Prtksxna So now, any user/IP in the filters will not be included by default in the block users form. They will be included in the dropdown menu, so you can add them if you want. This is regardless of whether or not the filtered out user/IP was a target in the original investigation.

The only problem I can see is if you have a lot of filtered out users/IPs the dropdown menu might get cluttered with users/IPs you are not interested in.

This is assuming that CheckUsers will make heavy use of filters.

There does not appear to be a limit to the number of users/IPs which can appear in the dropdown (I have had 50+ so far).

Also, in case you missed, you might want to take a look at T258488, which is an upstream bug affecting the widget we are using.

Thanks for flagging this, @dom_walden. Since we don't know how often filters might be used, we should hold off on fixing the clutter issue.

In T248530#6327370, @Niharika wrote:

Thanks for flagging this, @dom_walden. Since we don't know how often filters might be used, we should hold off on fixing the clutter issue.

OK, thanks. I have nothing more I want to do here then.