Moving to the next sprint, as it should not be a huge lift and would be a nice UX improvement.

It would be nice to also support prefix search, like the guc.toolforge.org app, to be able to do a query like this https://guc.toolforge.org/?isPrefixPattern=1&user=%7E2024-. Maybe that should have its own task.

Change #1101895 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/CheckUser@master] [WIP] Allow searches for temporary and registered accounts on Special:GlobalContributions

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

In T375632#10276032, @kostajh wrote:

It would be nice to also support prefix search, like the guc.toolforge.org app, to be able to do a query like this https://guc.toolforge.org/?isPrefixPattern=1&user=%7E2024-. Maybe that should have its own task.

This was explored in the user testing phase, and was found not to be very popular as summarized here. (For the benefit of anyone who can't access that, it was unclear to some users how it would work, and was expected to be used for IP ranges, in the absence of a proper IP range search.)

I don't think it's captured in a task, but if it's needed, a separate task would be nice, to contain the scope of this task.

I went ahead and split the task off into it's own ticket here.

@KColeman-WMF Could I get your opinion on some of the copy/states that will result from this change? I've noted some suggestions in case it's useful.

Since this will now take registered usernames and temporary accounts, the IP-specific copy needs be updated:

Input:

Could be changed to "Username, IP address, or IP range"/"Enter a username, IP, or IP range to see contributions"

Subheading:

Could be changed to "Showing results from the last 90 days, for all wikis where you have the right to view contributions." There will be an update to permissioning as well and "contributions" in this case could mean either IP contributions which are limited to people with the viewer right and/or (of this update) suppressed/deleted revisions for registered accounts as those are also gated behind another permission.

Error states have also changed a bit, as we can no longer be sure someone is entering an invalid IP or a username that looks like an invalid IP and this error state has been removed. These are the states as they look now with some notes:

State	Screenshot	Notes
Valid IP range but out of range		No change needed
Valid IP or range but no results		Shouldn't need a change, unless error states are combined (see registered account errors) as this will only show up if an IP is used
User doesn't exist		This matches with the error we used to throw when an invalid IP/range was passed. For additional context, Special:Contributions throws a nicer user-facing error which we may want to emulate for consistency:
User exists, no visible contributions		Shouldn't need a change unless we want to standardize w/the no results from IP state

Do these look okay and if not, what should they look like instead? Thanks!

In T375632#10403344, @STran wrote:

@KColeman-WMF Could I get your opinion on some of the copy/states that will result from this change? I've noted some suggestions in case it's useful.

Since this will now take registered usernames and temporary accounts, the IP-specific copy needs be updated

Thanks @STran! Yes we do need to update the copy. I like your suggestions, with a tiny tweak to input:

I agree with your suggestions for error messages. We can use the following:

Scenario	Mockup	Type	Message
Valid IP range that's out of range		Error	Same as before
Valid IP or range with no results		Notice	Same as before
User doesn't exist		Warning	No results matching the query. User “Admin2” is not registered.
User exists with no visible contributions		Notice	No results matching the query. User “Admin2” has no visible contributions.

@KColeman-WMF Thanks! I got some additional information for the "User doesn't exist" state that I think will affect it. It's possible that the searcher doesn't have permission to see the target user (eg. the target is suppressed and only users who have the right permissions can see them). There are 2 permissions that can affect this, hideuser which applies locally and centralauth-suppress which applies globally.

If you cannot see a user, I believe you shouldn't be aware that they exist at all:

State	Screenshot
Has right to see suppressed user
Cannot see suppressed user

I think the copy should reflect this? eg. "No results matching the query. User “Admin2” is not registered or you do not have permission to view this user."

In T375632#10409691, @STran wrote:

@KColeman-WMF Thanks! I got some additional information for the "User doesn't exist" state that I think will affect it. It's possible that the searcher doesn't have permission to see the target user (eg. the target is suppressed and only users who have the right permissions can see them). There are 2 permissions that can affect this, hideuser which applies locally and centralauth-suppress which applies globally.

If you cannot see a user, I believe you shouldn't be aware that they exist at all:

State	Screenshot
Has right to see suppressed user
Cannot see suppressed user

I think the copy should reflect this? eg. "No results matching the query. User “Admin2” is not registered or you do not have permission to view this user."

Good spot! Just to be clear, do we know if the user running the query has permission to see a suppressed user? In which case we can show them a message explaining that. Or do we need one message that covers a user not being registered and a user being suppressed?

In T375632#10410990, @KColeman-WMF wrote:

Good spot! Just to be clear, do we know if the user running the query has permission to see a suppressed user? In which case we can show them a message explaining that. Or do we need one message that covers a user not being registered and a user being suppressed?

We do know whether they have the right to see a suppressed user or not, but when a user is suppressed we are supposed to deny their existence - i.e. the site should show the same thing as for a nonexistent user. Otherwise, there could be a risk that someone would try different user names to find existing, suppressed ones.

I'm sorry @KColeman-WMF, I think this may have been an engineering question in the end but I'd appreciate it if you could confirm/deny our conclusion? If a user is suppressed and you cannot see the user, the user doesn't exist to you. My concern was that if you on a local wiki looked up a local suppressed user, you would get the "User not registered" message whereas because Special:GC doesn't know that, it can find the central account and the user is considered registered (but with no contributions). I chatted through this with @Tchanders and we agreed that it's fine if the global account still shows (as opposed to the "User not registered" message) as you can't work out what wiki, if any, the user is registered on since no contributions show. That means a user with an account and no contributions and a suppressed user will show up similarly on Special:GC, which we think is in line with our intent with suppressed users (per Thalia's note above about an attack surface). As such, copy shouldn't mention permissioning at all.

This should be the updated table of states:

Scenario	Mockup	Type	Message
Valid IP range that's out of range		Error	Same as before
Valid IP or range with no results		Notice	Same as before
1. User doesn't exist or 2. is suppressed globally and viewer has no access		Warning	No results matching the query. User “Admin2” is not registered.
1. User exists with no visible contributions or 2. user is suppressed on all local wikis and viewer has no access		Notice	No results matching the query. User “Admin2” has no visible contributions.

@STran Thanks for the update. This makes sense to me!

Change #1109715 had a related patch set uploaded (by STran; author: STran):

[mediawiki/core@master] Refactor ContributionsSpecialPage->contributionsSub to support markup overrides

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

Change #1109715 merged by jenkins-bot:

[mediawiki/core@master] Refactor ContributionsSpecialPage->contributionsSub to support markup overrides

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

Change #1101895 merged by jenkins-bot:

[mediawiki/extensions/CheckUser@master] Allow searches for temporary and registered accounts on Special:GlobalContributions

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

Design query: at the moment, when viewing the global contribs for a registered account, the account’s username is listed next to each entry (although not for edits made at metawiki?). While this makes sense for searching for the global contribs for an IP address (given that they may be from multiple different temporary accounts), should this still be present when viewing the global contribs for a specific account, given that the username will be the same for all returned revisions? (Let me know if it’d be better if I filed a new task for this)

In T375632#10511820, @A_smart_kitten wrote:

Design query: at the moment, when viewing the global contribs for a registered account, the account’s username is listed next to each entry (although not for edits made at metawiki?). While this makes sense for searching for the global contribs for an IP address (given that they may be from multiple different temporary accounts), should this still be present when viewing the global contribs for a specific account, given that the username will be the same for all returned revisions? (Let me know if it’d be better if I filed a new task for this)

@KColeman-WMF, what do you think about this? (And yes, @A_smart_kitten, a new task for this would be preferable, thanks!)

@kostajh split to T385285: Consider not displaying the username next to each edit in Special:GlobalContributions when searching for a specific account :)

In T375632#10511820, @A_smart_kitten wrote:

Design query: at the moment, when viewing the global contribs for a registered account, the account’s username is listed next to each entry (although not for edits made at metawiki?). While this makes sense for searching for the global contribs for an IP address (given that they may be from multiple different temporary accounts), should this still be present when viewing the global contribs for a specific account, given that the username will be the same for all returned revisions? (Let me know if it’d be better if I filed a new task for this)

Thanks for raising this! The spec for Special:GlobalContributions follows the same functionality as https://guc.toolforge.org/ (which also includes a username that links to the relevant project). As mentioned on the other task, there should ideally be a contribs link next to the talk link.

I have tried looking up Special:GlobalContributions for various temporary and named users on my local environment. So far, I have found no missing revisions.