In T412221#11454835, @hector.arroyo wrote:

Linking to Special:IPContributions will reveal the IP behind the temporary account. Should we log that reveal?

We could link to an intermediary controller that receives the username, and redirects the user to the appropriate IPContributions URL, i.e. link to something like http://localhost:9825/wiki/Special:IPContributions/user/~2025-1234 that returns an HTTP 3xx pointing to http://localhost:9825/wiki/Special:IPContributions/1.2.3.4.

That way we won't de disclosing the IP in the UIC endpoint, and we could log the access in the controller that handles the redirection.

@Niharika Linking to Special:IPContributions will reveal the IP behind the temporary account. Should we log that reveal?

Can you please share a screenshot of the end result?

In T412218#11450853, @kostajh wrote:

In T412218#11450676, @mszwarc wrote:

• Add "Temporary accounts from all associated IPs" (surfaced in UserInfo card) on:
  • Special:Contributions (temp account)

@Niharika Should this information be gated behind some right? Currently, this number is available only in UIC, so only registered users can see this data. When we embed it onto contributions, it'll be viewable by anyone. Is that okay?

Is it possible to make it visible to registered users only?

It's possible as well.

• Add "Temporary accounts from all associated IPs" (surfaced in UserInfo card) on:
  • Special:Contributions (temp account)

@Niharika Should this information be gated behind some right? Currently, this number is available only in UIC, so only registered users can see this data. When we embed it onto contributions, it'll be viewable by anyone. Is that okay?

Moving back to backlog to finish the last step (Surface these in the Temporary Accounts grafana dashboard), once the events start coming in – next week.

In T402896#11450055, @EChukwukere-WMF wrote:

@mszwarc I believe I have the latest version of media wiki. I tried to navigate from other logs then to "user creation logs" I still don't see the "Exclude temporary account creations" checkbox checked.

Let me know if I am missing something

From a quick codesearch, it seems that two places may need updating:

• repo/domains/crud/src/Infrastructure/DataAccess/EntityUpdater.php
• repo/domains/crud/tests/phpunit/Infrastructure/DataAccess/EntityUpdaterTest.php

In T412011#11446005, @Izno wrote:

Apparently Parsoid doesn't have the mw-tempuserlink class.

In case a community is interested in updating their version of noping template, below is an example updated code of Module:No_ping, which can be used on wikis where the implementation is inspired by enwiki's.

-- This module implements {{no ping}}.

Moving to done – the fix has been on prod for two weeks now, we can assume everything works fine

Following a discussion on Slack, we're going to stick with Option 3 ("do nothing") for now. If we were to build an API for gadgets, it should happen in T372180.

Skipping QA, as this is a trivial change and was verified by devs

Given the above outline, I propose that we take the option 3 ("do nothing").

It should be fixed now, as we fixed the mw-userlink class not to be applied to the tool links (in T392775#11418344).

It seems that the hyphen is present in the REST API response: https://pl.wikisource.org/api/rest_v1/page/html/Dziewczyna_bezimienna%2FCz%C4%99%C5%9B%C4%87_druga%2FXVIII (look for "doprawdy, że cza-"). On the other hand, the hyphen is not present in the Action API response (https://pl.wikisource.org/w/api.php?action=parse&format=json&page=Dziewczyna%20bezimienna%2FCz%C4%99%C5%9B%C4%87%20druga%2FXVIII&formatversion=2) nor in the normal read mode.

On average, a temporary account exists on 3.06 wikis (there are 1.415M global temp. accounts and 4.330M local temp. accounts). 95% of temporary accounts are attached to 4 wikis or less, which in practice means we'll usually need to perform up to 2 requests to reveal the IPs (no account is excepted to have edits on loginwiki and very few edited on metawiki).

In T400577#11433173, @Tchanders wrote:

Not working in dark mode isn't really a problem, because the current highlighting doesn't do much in dark mode anyway

Apart from implementing it for action=query&list=users, I think we should also do it for action=query&list=allusers for parity

I'll implement the proposed solution using the "default link text" concept.

In T410636#11412516, @Niharika wrote:

In T410636#11412424, @Tchanders wrote:

@Niharika What if we made some permanent visual difference between the most recent IPs and IPs associated with the particular action/edit, than also implemented a tooltip to explain what that difference meant?

In the absence of better design, something like (1.2.3.4*)?

I thought about this too but decided against proposing this because we are already making temporary accounts quite crowded with the gray background, Show IP, IP Info tooltip and the User Info card icon. I don't want to add to that. Another way to do this is to add a message in the IP Info card (since the IP Info will follow from the IP that is being made visible). We can do this in addition to the tooltip.

Hi and sorry for breaking things...

In T392775#11410961, @cscott wrote:

That is, instead of starting by applying styling to all mw-tempuserlink and then trying to restrict where that class appears, does it make more sense to apply mw-tempuserlink to all links to temporary users and then restrict where the *styling* applies?

In T410636#11400196, @mszwarc wrote:

next to a signature of a temp. account, it is theoretically possible to connect the user to a specific revision (which is done e.g. for the Thank button in DiscussionTools)

There are a number of subtle issues there with respect to HTML and URL encodings and language variants (language conversion can alter the digits in the temp account name, have you tested this?)

Thanks for pointing it out. I tested it locally in a few configrations, but for sure there can be one that I didn't think of and that will break (e.g. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1210512/comment/48a8d1f1_bf42e051/ ).

In T410636#11404817, @Dreamy_Jazz wrote:

With the second one, I would note that there are issues with just reading the username from the DOM as described in T392522: IP reveal: IP reveal fails if the temporary account is expired. However, I guess reading the link target could avoid that issue?

From the engineering point of view I see two approaches to this:

I've submitted all the patches needed for this task:

What IP should be displayed for a given temp user? Should it be simply the last one used or some specific one?

In T117884#11394207, @Pppery wrote:

Could this please be done without making everything take up 2 or 3 times as much vertical space as it did in the previous version. All of these UI "modernization" things end up making things worse in that way in my opinion.

In T347209#11391271, @Niharika wrote:

@mszwarc If the technical approach has been identified we can close this task. I think we can use T392775 for adding the highlight (I'll add more details to it) and I can spin up other tasks to 1) support show IP and auto-reveal and 2) support user info card.
Does that sound okay?

I'll work on this to fix the previous attempt (as described in T347209#11388235).

In T347209#11387972, @Tchanders wrote:

In T347209#11382430, @mszwarc wrote:

Given that T398952#10994965 implies that the coloring should be done not only based on the link target, but also the text content of the link, I'm thinking if the approach from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1139193 could be extended so that LinkRenderer::getLinkClasses accepts a second, optional parameter for the link label, and the gray background is based on its value. The text would be passed from make{Known,Broken}Link(), which already have access to it. Is this feasible?

I think this approach shouldn't cause the side effects that appeared originally (T398714, T398717, T398952), because none of these places used link text equal to the temp. username.

I think this makes sense to try.

There may be some edge cases where we'd be adding the class to links that shouldn't have it, which we're picked up last time due to being more obscure (though I can't think what these would be). If there are, we may be able to fix those via the IP reveal software in CheckUser.

There are still a few usages of User::getRegistration() in the production code. However, as it less and less related to the actual projects the PSI team is working on, I'll unassign myself from this task and stop here. To reflect that, I'm moving this task to the Done column on our sprint board.

In T399177#11378169, @Niharika wrote:

I encountered this issue again today. The notice does not disappear after 30 seconds as it should.

Moving to Done. I think the fix is simple enough that it doesn't need QA.

Given that T398952#10994965 implies that the coloring should be done not only based on the link target, but also the text content of the link, I'm thinking if the approach from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1139193 could be extended so that LinkRenderer::getLinkClasses accepts a second, optional parameter for the link label, and the gray background is based on its value. The text would be passed from make{Known,Broken}Link(), which already have access to it. Is this feasible?