This is awaiting input about how we will use the information, and therefore whether the table in the task description is the correct information to gather. Moving it to Needs Refinement to reflect this.

One more question! From the task description:

Thanks @Strainu - I experienced roughly similar timings to get multilingual revert risk scores via the internal stats server (about 15 minutes for 4-5k revisions).

Thank you @Dzahn! Public key:

Thanks @Samwalton9-WMF - that helps!

Looks like we'll need to make API calls for the multilingual revert risk scores (until T415892, but I'd like to make a start straight away). Then we can do something like what was done in the previous analysis for actual reverts.

Specifically, this happens if the first revision line is from a temporary account who wasn't the original target.

Specifically, this happens if the first revision line is from a temporary account who wasn't the original target.

For blocks, we saw a reduction in the proportion of IP blocks, again similarly to before.

With @nettrom_WMF's help, I re-ran the analysis conducted on major pilot wikis, on enwiki, eswiki, commonswiki and wikidatawiki.

Here is our original discussion on logging: T376315#10413649.

I suppose this is because the new global group was not initially populated with the users belonging to relevant local groups, so the change took effect the next time the local group membership was changed in any way?

@STran Thanks for the analysis - repo available at https://gitlab.wikimedia.org/stran/statstbd

I found more questions while implementing this:

• If the exact count is 1, should we omit the warning box? This could help patrollers quickly see whether there might be more to investigate with this temp account. I implemented this.
• Should we change the link to hide the related accounts if they are currently shown? I implemented this too.
• Are we allowed to show the exact number of temp accounts and IPs without logging that the user saw this? If we have to log it, we will be making a log every time a user with IP reveal visits a temp user contributions page, which will be a lot of logspam. Until we can answer this, I've implemented the bucketed count only, so as not to expose private data unlogged to users.

Perhaps we could add an extra column for restrictions, though this would take up a lot of space given that it's rare to have a group with restrictions. Though it may get less rare.

Investigating whether we need to limit the number of related temp users looked up

In T415703#11562087, @Dreamy_Jazz wrote:

In T415703#11561847, @Tchanders wrote:

We could also narrow the maximum range for this type of query - for example only allow single IPs (but treat IPv6 as /64).

Sure, though AFAICS the problematic query mentioned in the task description was for a /64 IPv6 range

We could also narrow the maximum range for this type of query - for example only allow single IPs (but treat IPv6 as /64).

Re: query performance, see also T415703, which uses the same query.

I'm not quite sure where the number of rows is coming from. Some related numbers:

• There are about 35000 rows in cu_changes on that range
• There are about 2500 temp account rows in cu_changes on that range

In T414963#11538163, @Tchanders wrote:

Moving to review since there are patches to review, but we're awaiting an answer from Legal about whether access to related temporary accounts needs to be logged, before all the code can be merged.

In T398673#11508154, @STei-WMF wrote:

Given T377771#11493552, IMO this feature could maybe benefit from an announcement in Tech/News. Boldly tagging as such :)

@A_smart_kitten thanks! @Tchanders how might we word this for Tech News?

I looked into whether it would be feasible to simply update Special:Contributions and Special:Log to take multiple targets. A few things complicate this, as detailed below.

Moving to review since there are patches to review, but we're awaiting an answer from Legal about whether access to related temporary accounts needs to be logged, before all the code can be merged.

It seems the easiest to just wait for TA deployment to ruwiki (unless it's going to take ages).

In T413216#11480994, @STran wrote:

Without doing additional prep work:

• Talk pages will always be blue, as there won't be an external check to see if the talk page exists
• Contribs won't support redContribsWhenNoEdits (UserRights sets this to false so it's no difference in this use case

This probably needs a 2-part fix:

1. stop running the maintenance script on labs (https://gerrit.wikimedia.org/r/1219619)
2. update UpdatePeriodicMetrics to make sure it doesn't try to collect CheckUser metrics if CheckUser is not installed

Leaving open until we confirm that the logs are no longer made.

Moving this task to Done, but will leave it open until CheckUserLogMaxRangeToShowInLog is configured for WMF