Blocked on T324603

In T324602#8485053, @Tchanders wrote:

Blocked on T324603

This can be implemented/tested using the patch for T324603: The CheckUser extension should provide IP addresses of temporary account users, for IP Masking

Change 893843 had a related patch set uploaded (by TsepoThoabala; author: TsepoThoabala):

[mediawiki/core@master] SpecialBlock: Once a temporary account is selected, below the username field display IP addresses associated with the account

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

@Prtksxna I have a few design questions. I don't think they should block this task - we can file follow-ups instead.

• The user input label in the screenshot says "Username, temporary username, or IP range", but this doesn't make sense on wikis where temp accounts are not enabled. What should we do?
• Similar question about how we should update the placeholder
• What should happen if the Admin does not have access to view temp account IP addresses - e.g. because they haven't enabled the preference - should we prompt them, or should we show nothing at all?
• What should happen if no IP addresses are returned - e.g. if they are no longer stored because it has been >90 days - should we display an error, or should we just display nothing?

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

[mediawiki/extensions/CheckUser@master] Show IP addresses for temporary accounts when selected in Special:Block

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

Testing notes
First make sure that revealing IP addresses for temporary accounts is enable in preferances.
I tested by going to Special:Block, and then inputting a temporary user in the target user textbox.
I tested that I can see the IP address below the text field
I checked that 'and' only separates the last two IPs and the rest are separated by ','
I checked that there are no errors on the page/in console while testing this.

• The user input label in the screenshot says "Username, temporary username, or IP range", but this doesn't make sense on wikis where temp accounts are not enabled. What should we do?
• Similar question about how we should update the placeholder

If we can check whether temp accounts are enabled and change the label and placeholder accordingly then we should do that. If not, I think we should keep the labels and placeholder the same as now and file a task for changing this when all wikis have temp accounts enabled. Considering third-party wikis would that ever happen?

If we can change based on config then:

Is the format of the temporary usernames configurable? If it is, then the placeholder might become tricky.

• What should happen if the Admin does not have access to view temp account IP addresses - e.g. because they haven't enabled the preference - should we prompt them, or should we show nothing at all?

A quick question here - is this the preference that you were telling me about over our most recent video call? Is this effectively the NDA preference, or something else?

I think it is a good place to remind Admins that they could have access to IP data, @Niharika any reasons not to?

• What should happen if no IP addresses are returned - e.g. if they are no longer stored because it has been >90 days - should we display an error, or should we just display nothing?

I don't think not having the IP data as per policy should count as an error. We should show a text label No IP data for this temporary user for the last X days.
@Niharika was there some discussion around the IP retention duration for temp users being more than the usual 90 days?

Happy to file follow-up tasks for whatever we decide.

In T324602#8690912, @Prtksxna wrote:

• The user input label in the screenshot says "Username, temporary username, or IP range", but this doesn't make sense on wikis where temp accounts are not enabled. What should we do?
• Similar question about how we should update the placeholder

If we can check whether temp accounts are enabled and change the label and placeholder accordingly then we should do that. If not, I think we should keep the labels and placeholder the same as now and file a task for changing this when all wikis have temp accounts enabled. Considering third-party wikis would that ever happen?

If we can change based on config then:

Label	Username, temporary username, IP address, or IP range:
Placeholder	UserName, *Unregistered42, 1.1.1.42 or 1.1.1.42/16

Is the format of the temporary usernames configurable? If it is, then the placeholder might become tricky.

We can check the config and change the message accordingly.

I don't think it's decided whether IP editors will be removed from MediaWiki for everyone eventually, but if so it would presumably be in the distant future, since it would need discussion.

The temporary username format is configurable, so this would be awkward but not impossible. Is it important to highlight temporary user names separately, or are we just very aware of them because we're currently working on them?

• What should happen if the Admin does not have access to view temp account IP addresses - e.g. because they haven't enabled the preference - should we prompt them, or should we show nothing at all?

A quick question here - is this the preference that you were telling me about over our most recent video call? Is this effectively the NDA preference, or something else?

It's the preference added in T326736: Create preference for viewing IP addresses used by temporary accounts.

I think it is a good place to remind Admins that they could have access to IP data, @Niharika any reasons not to?

• What should happen if no IP addresses are returned - e.g. if they are no longer stored because it has been >90 days - should we display an error, or should we just display nothing?

I don't think not having the IP data as per policy should count as an error. We should show a text label No IP data for this temporary user for the last X days.
@Niharika was there some discussion around the IP retention duration for temp users being more than the usual 90 days?

---

Happy to file follow-up tasks for whatever we decide.

Thank you!

Change 893843 merged by jenkins-bot:

[mediawiki/core@master] Update specialblock target text to use usersmultiselect.

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

Change 896358 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Show IP addresses for temporary accounts when selected in Special:Block

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

Problem found with this which has been reported as T332136.

@TThoabala Please see results below. As an Admin I can view the IP addresses no matter what even if I checked or unchecked Checkuser. Blocked accounts of course can't even get on the Special:Block page as expected.

OS: macOS 13.2
Browsers: Safari 16.3, Chrome 111, Firefox 111
Environment: Local

Unblock Admin- Used Admin account to block another admin account in Testuserone. Testuserone was able unblock themselves even though the account is blockeds via Special:Contributions. After the account was unblocked, I was able to go to Special:Block but as seen in the screenshot when inputting *Unregistered 4, it did not show the IPs associated with the account.

Multiple IPs (7x): 7 different IPs for *Unregistered 4 but shows the last 3 in Special:Block. As Designed?

Safari- Disable JS. As Designed?

Different Language- No issues, just showing that it's good

In T324602#8690912, @Prtksxna wrote:

• What should happen if the Admin does not have access to view temp account IP addresses - e.g. because they haven't enabled the preference - should we prompt them, or should we show nothing at all?

A quick question here - is this the preference that you were telling me about over our most recent video call? Is this effectively the NDA preference, or something else?

I think it is a good place to remind Admins that they could have access to IP data, @Niharika any reasons not to?

Can't think of any reasons not to. Sounds like a good idea.

• What should happen if no IP addresses are returned - e.g. if they are no longer stored because it has been >90 days - should we display an error, or should we just display nothing?

I don't think not having the IP data as per policy should count as an error. We should show a text label No IP data for this temporary user for the last X days.
@Niharika was there some discussion around the IP retention duration for temp users being more than the usual 90 days?

IP address retention will be limited to 90 days as it stands currently. I am in a long-ongoing conversation with Legal and to elongate that but we need data to convince them that this is necessary.
For now, we should assume that the limit is 90 days but keep in mind that it can change in the future.

Some records in the future are likely to be held for longer.

@TThoabala I do have a few more questions too as seen below, thanks!

Temporary user does not have any IPs in the database - This happens if they have not made an edit in the last 90 days. Should this be blank or say something else?

CheckUserMaximumRowCount- Is it supposed to use the number I have in my Local or is it supposed to be my most recent 3 IP addresses?

Hello I'm not sure if I'm in the right place but I noticed today a change on the Special:Block page : it is not possible to type in the IP field on block page. It was very useful and often used to add a subnet mask (like /64 for IPV6 or /24 for IPV4) on the right of the IP address. It is not possible anymore with this new widget. This is pretty annoying. Do you think it is possible to fix this ?
For info, I'm on French Wikipedia using Vivaldi browser.

In T324602#8722779, @Shawn wrote:

Hello I'm not sure if I'm in the right place but I noticed today a change on the Special:Block page : it is not possible to type in the IP field on block page. It was very useful and often used to add a subnet mask (like /64 for IPV6 or /24 for IPV4) on the right of the IP address. It is not possible anymore with this new widget. This is pretty annoying. Do you think it is possible to fix this ?
For info, I'm on French Wikipedia using Vivaldi browser.

Hi @Shawn - yes, this is the right place, since the field was changed as part of this task. I'm trying to understand what's happening: is the problem that you visited Special:Block/<someIPaddress> and found that the IP was entered in the field, but you couldn't edit it - you could only remove it and type it out again?

Hello @Tchanders, yes you're right. I did't specify the full use case.
Yes I'm arriving on the block page from the contributions list of an IP, so the page URL is Special:Block/<someIPaddress> and the IP text field is already filled with the IP and cannot be changed. You have to remove it and type it again manually.
Moreover, it is impossible to select the IP address to copy/paste in the field because when you try to select it with mouse it starts a drag & drop of the IP, double click does't select neither. It is not possible either to use keyboard for selection in that widget.

The user experience was really more efficient in the past as we just had to click in the field and add "/64" then enter...

Thanks for clarifying @Shawn - I've filed a task and suggested a fix here: T332994

In T324602#8712185, @GMikesell-WMF wrote:

@TThoabala I do have a few more questions too as seen below, thanks!

Temporary user does not have any IPs in the database - This happens if they have not made an edit in the last 90 days. Should this be blank or say something else?

CheckUserMaximumRowCount- Is it supposed to use the number I have in my Local or is it supposed to be my most recent 3 IP addresses?

@GMikesell-WMF I think this was mentioned here

I don't think not having the IP data as per policy should count as an error. We should show a text label No IP data for this temporary user for the last X days.

I have filed this T333514 task cc @Prtksxna , @Tchanders.

In T324602#8700556, @GMikesell-WMF wrote:

@TThoabala Please see results below. As an Admin I can view the IP addresses no matter what even if I checked or unchecked Checkuser. Blocked accounts of course can't even get on the Special:Block page as expected.

OS: macOS 13.2
Browsers: Safari 16.3, Chrome 111, Firefox 111
Environment: Local

Unblock Admin- Used Admin account to block another admin account in Testuserone. Testuserone was able unblock themselves even though the account is blockeds via Special:Contributions. After the account was unblocked, I was able to go to Special:Block but as seen in the screenshot when inputting *Unregistered 4, it did not show the IPs associated with the account.

I've checked this locally and it seems to work fine. Might have been another bug that got solved since.

Multiple IPs (7x): 7 different IPs for *Unregistered 4 but shows the last 3 in Special:Block. As Designed?

Looks like this has been fixed too:

Safari- Disable JS. As Designed?

This is caused by an underlying bug - fixed in T333581: TagMultiselectWidget in no-JS mode should not have more rows than the number of tags.

In T324602#8712185, @GMikesell-WMF wrote:

@TThoabala I do have a few more questions too as seen below, thanks!

Temporary user does not have any IPs in the database - This happens if they have not made an edit in the last 90 days. Should this be blank or say something else?

@TThoabala Thanks for filing T333514: Show a text label when there is No IP data for temporary user on Special:Block.

CheckUserMaximumRowCount- Is it supposed to use the number I have in my Local or is it supposed to be my most recent 3 IP addresses?

This is another bug - filed as T333583.

Thanks for raising these @GMikesell-WMF . They seem to be resolved or filed as follow-ups, so I'll move this task to Done.

Proper debouncing should be used (OO.ui.debounce) instead of changing the input field type.

Change 904602 had a related patch set uploaded (by Func; author: Func):

[mediawiki/extensions/CheckUser@master] SpecialBlock.js: Use debounce on API request

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

Change 904704 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] Revert "Update specialblock target text to use usersmultiselect."

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

In T324602#8747525, @Func wrote:

Proper debouncing should be used (OO.ui.debounce) instead of changing the input field type.

Copying over from Gerrit:

This isn't a debouncing issue - it's not just that we want the API calls to be performed less frequently. We need them to only be called when a user has finished being entered, not just for performance reasons, but for the oversight logs. Temporary users are very likely to have names that are substrings of each other, so we can't just check for a valid value.

The multiselect is convenient here because, unlike the user input it has a built-in distinction between accepted input vs in-progress; and it is used in Special:CheckUserBlock (which allows blocking multiple users) so this makes the two forms more similar.

If there's a particular UI problem that this is causing, we can look into fixing it, and if there are many such problems, we can look into whether it's worth implementing some customised fixes to allow us to use the user input.