See also T310393 for some concerns.

@Bugreporter, anything I can help with (specifically anything related to CheckUser)? If so, if you could add me to the task.

@RHo I have a design question about the (Show IP) buttons:

In the screenshots they are styled like links, but they behave as buttons. They don't navigate to another page like links; instead they fetch some data and update the appearance of the page when clicked.

Technically it's a bit awkward to do this. We can make a button using the UI component library, and tell it what to do when a user clicks. But to style this to look like a link would take a lot of custom CSS, which can end up being fragile. For me, whenever we seem to be fighting the component library it raises the question: should we be doing this (i.e. should we be styling a button to look like a link)? Do we have any style guidelines about whether the user should be able to distinguish a link from a button by their appearance?

In T325238#8543376, @Tchanders wrote:

@RHo I have a design question about the (Show IP) buttons:

In the screenshots they are styled like links, but they behave as buttons. They don't navigate to another page like links; instead they fetch some data and update the appearance of the page when clicked.

Technically it's a bit awkward to do this. We can make a button using the UI component library, and tell it what to do when a user clicks. But to style this to look like a link would take a lot of custom CSS, which can end up being fragile. For me, whenever we seem to be fighting the component library it raises the question: should we be doing this (i.e. should we be styling a button to look like a link)? Do we have any style guidelines about whether the user should be able to distinguish a link from a button by their appearance?

Hi @Tchanders - this is something that has come up recently relating to these "buttons styled as links" being in many places on wiki. I know of one task T320798 ongoing to stop adding a visited colour style to these elements, with examples being hide in the table of contents on pages, thank, undo, and the reply action on old Talk pages.

Some initial ideas about how to add the "show IP" action when it is appearing after the temp account name inline:

• Proposal 1 (short term): Add square brackets – Given historically the amount of places where these button links are used, we could keep this convention for now but surround it with square brackets to help indicate it is meant to be an action, i.e., [ show IP ]. It's less disruptive and follows what similar actions do, but seems not great to add to list of not-best-practice applications.
• Proposal 2 (short term fix): Quiet button – Continuing to use OOUI library, DiscussionTools chose to use a quiet neutral button for the 'reply' action. We could do this too, and experiment with using a quiet icon with or without an icon to better distinguish it as an action. The trade off is possible it will visually bit off in certain places where it will be shown, possibly increasing line-spacing. It will also stand out from other actions like undo and thanks in cerrtain places.

Example of Reply quiet button on DT	Quick mock of how this could look in edit history

My inclination is proposal 2, and flag this as a possible new variant for the Codex folks to to consider for the button component - small buttons shown with inline text.
What do you think?

My inclination is proposal 2, and flag this as a possible new variant for the Codex folks to to consider for the button component - small buttons shown with inline text.
What do you think?

Just noting here that we agreed on option 2 in our meeting (and having discussed with @Niharika too) - thanks @RHo!

In T325238#8557877, @Tchanders wrote:

My inclination is proposal 2, and flag this as a possible new variant for the Codex folks to to consider for the button component - small buttons shown with inline text.
What do you think?

Just noting here that we agreed on option 2 in our meeting (and having discussed with @Niharika too) - thanks @RHo!

Discussed this with Rita yesterday to confirm. We're good to go with option 2 with a capital "S" on "Show IP".

I have an update on these requirements after talking through this at length with legal, engineering and design.

For context:

• @Tchanders and @STran have pointed out challenges with implementing the pair-reveal workflow for patrollers (T327947#8736059 and T327947#8744976).
• @JJMC89 and @Dreamy_Jazz have pointed out concerns with limiting the longevity of the logs in T325658: Log access to IP addresses of temporary accounts

Here's the update:

• We keep the reveal workflows consistent for admins and patrollers. For both groups, revealing an instance of the temporary username will reveal all IPs associated with that username on that page and subsequent pages visited for a period of 24 hours after which they will need to reveal that temp username once more.
• We will drop the IP addresses from the log and persist the logs forever. If we aren't selectively revealing IPs for patrollers we likely don't need to explicitly track which IPs were revealed. This isn't perfect of course because IPs would be stored for 90 days only and by the time an oversighter comes by we may not have all the same IPs available in the database. However, this should ease oversight because logs will persist forever.

Questions? Concerns? @JJMC89, @Dreamy_Jazz?

In T325238#8777130, @Niharika wrote:

Here's the update:

Thanks for this. I have no questions or concerns. Rest of this comment is why I agree with these changes.

• We keep the reveal workflows consistent for admins and patrollers. For both groups, revealing an instance of the temporary username will reveal all IPs associated with that username on that page and subsequent pages visited for a period of 24 hours after which they will need to reveal that temp username once more.

I like this change. No concerns from what I see. Agree with the points that have been raised regarding the complication between the different levels of access that I've been seeing here and at gerrit. Also this should make the volume of log entries generated be greatly reduced which will help in performing oversight.

• We will drop the IP addresses from the log and persist the logs forever. If we aren't selectively revealing IPs for patrollers we likely don't need to explicitly track which IPs were revealed. This isn't perfect of course because IPs would be stored for 90 days only and by the time an oversighter comes by we may not have all the same IPs available in the database. However, this should ease oversight because logs will persist forever.

I think any need to see the IP that was revealed is not as important as keeping the logs past 90 days, so I welcome this change. Having the performer of the reveal, the temporary user who was revealed and the timestamp associated with this should be enough to properly oversight the use of the tool.

In T325238#8777342, @Dreamy_Jazz wrote:

In T325238#8777130, @Niharika wrote:

• We will drop the IP addresses from the log and persist the logs forever. If we aren't selectively revealing IPs for patrollers we likely don't need to explicitly track which IPs were revealed. This isn't perfect of course because IPs would be stored for 90 days only and by the time an oversighter comes by we may not have all the same IPs available in the database. However, this should ease oversight because logs will persist forever.

I think any need to see the IP that was revealed is not as important as keeping the logs past 90 days, so I welcome this change. Having the performer of the reveal, the temporary user who was revealed and the timestamp associated with this should be enough to properly oversight the use of the tool.

I agree. This is consistent with what is stored in the CU log.

Note in T356294#9504584 I propose the current Wikimedia Access to Temporary Account IP Addresses Policy be amended.

Will this tool restore the ability to get results currently available from Special:Contributions/IP/Mask -- frequently used by admins when considering and managing rangeblocks.

In T325238#9580588, @Xaosflux wrote:

Will this tool restore the ability to get results currently available from Special:Contributions/IP/Mask -- frequently used by admins when considering and managing rangeblocks.

There will be a way of seeing contributions from temporary accounts from a given IP range, but exactly how is under discussion on T356290#9565086.

That is a subtask of the global user contributions work that we're doing - the same idea but for global contributions.