My suspicion, though, is that there's not going to be much to update. Temporary accounts will look like regular user accounts in terms of public facing data in the replicas. Private data for those accounts will be in CheckUser tables that are not visible on the replicas.

Also noting that temporary accounts are already live on testwiki and test2wiki (since July), so you should be able to check for any concerning issues based on temporary account creations that happened on those wikis already.

@fnegri is there a list of views/filters with a description of their purpose, that we could review?

Unassigned myself in case someone else wants to take this one this week.

In T376612#10249102, @dom_walden wrote:

Going to https://test.wikipedia.org/wiki/Special:GlobalContributions as my staff account redirects to https://meta.wikimedia.org/wiki/Special:GlobalContributions.

I notice that if I include a target in the page title (e.g. https://test.wikipedia.org/wiki/Special:GlobalContributions/127.0.0.1) this is not preserved in the redirect (I get redirected to https://meta.wikimedia.org/wiki/Special:GlobalContributions). Depending on what the links to Special:GlobalContributions are like on local wiki, we might want to preserve the subpages. @kostajh

One part of this task is not yet done (seeing usernames next to pages) but the rest can start in QA.

This has been known for a while but we didn't really care. With the central session being more crucial for temp users, maybe we should. We could change the final step of central autologin to be two top-level redirects instead of one subresource request - that would make login and signup slower by a few hundred milliseconds, but it would also make the central session more reliable.

In T374942#10242904, @Jdlrobson wrote:

I am a little worried about how "The team’s instrumentation (schemas and server-side/client-side instrumentation code) is ready to work with Temp Accounts" is open to interpretation by different parties as outlined in the 3 scenarios here.

In T342785#10244012, @Johannnes89 wrote:

This makes sense to me! I was perhaps being over-cautious with respect to linking IP addresses and temporary accounts.

given that only admins (who qualify for IP Reveal) can access Special:Nuke, I don't think this is an issue – although I wonder if it's ok to link IP and temporary account at Special:Nuke, if the admin didn't agree to the Access to Temporary Account IP Addresses Policy via Special:Preferences.

In T375881#10242506, @STran wrote:

Found the problem:

./main.sh: line 169: ./import.sh: Argument list too long

Looks like the command is choking trying to ingest a ~4k file list on the command line. We can probably fix this by reading from an actual file instead of passing through all the filenames as a parameter. In the meanwhile, if we want to unblock daily updates, we should dump and reinit the database. Imports should continue as long as we're not asking it to parse a long import diff list.

Tagging with FY2024-25 WE4.2 as it's a hypothesis for Q2 work.

Pages should be listed without explicitly linking them to an IP address or temporary account.

In T375712#10240244, @RHo wrote:

bumping this to confirm this would be for @Niharika or @kostajh to complete?

In T373818#10230857, @KColeman-WMF wrote:

For comparison, this is the onboarding dialog with opt-in checkboxes for IP Info and IP Reveal. It does seem like a lot of text but on the plus side it means users can enable the setting quickly. Interested to hear feedback.

In T326940#10233458, @Soda wrote:

In T326940#10233435, @kostajh wrote:

In T326940#10233423, @Soda wrote:

@kostajh I think this a fragile stop-gap approach, since we are effectively breaking/disallowing this configuration from ever existing. Can you point out what exact work ProofreadPage 's pagequality extension needs (or how I can test if ProofreadPage works with temporary accounts) ? I'll be happy to test and/or make the necessary changes.

I think it would involve setting $wgAutoCreateTempUser['enabled'] = true; in your local environment, enabling the extension, and then checking the feature set of Proofread Page to validate that nothing is broken.

Hmm, tested, does not appear to have show-stopping bugs (no full-page errors),
Only one thing, I assume having the username as part of revision output like so:

<noinclude><pagequality level="3" user="~2024-1" /></noinclude>....<noinclude></noinclude>

is not a problem?

In T326940#10233423, @Soda wrote:

@kostajh I think this a fragile stop-gap approach, since we are effectively breaking/disallowing this configuration from ever existing. Can you point out what exact work ProofreadPage 's pagequality extension needs (or how I can test if ProofreadPage works with temporary accounts) ? I'll be happy to test and/or make the necessary changes.

The impact of change in build times is visible here https://grafana.wikimedia.org/goto/36K_ctiHR?orgId=1

In T326940#10233214, @gerritbot wrote:

Change #1080621 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[operations/mediawiki-config@master] ProofreadPage: Remove pagequality permission override

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

In T326940#10233123, @kostajh wrote:

In T326940#10229491, @Soda wrote:

@kostajh Why would the pagequality permission be unavailable to a temp account on their first edit ?

Sorry for the ambiguity. On dewikisource, Page and Index namespace content appears to be protected (e.g. https://de.wikisource.org/wiki/Index:Sammlung_alt-_und_mitteldeutscher_W%C3%B6rter_aus_lateinischen_Urkunden?action=info&uselang=en). That means that a not-logged-in visitor would not be able to make their first edit on such a page. With the existing config of $wgGroupPermissions['*']['pagequality'] = true; , if the visitor made an edit to e.g. the main namespace, they would have a temporary account--but actually, they would still not be able to edit the Page/Index content that is protected for autoconfirmed and above, because temporary accounts cannot be in the autoconfirmed group.

In T326940#10229491, @Soda wrote:

@kostajh Why would the pagequality permission be unavailable to a temp account on their first edit ?

Now that the patches are merged, I see that https://dumps.wikimedia.org/other/globalblocks/ is still present (not expected) and that the last run was on October 5 (expected). I think we can mark this task as resolved once https://dumps.wikimedia.org/other/globalblocks/ is no longer online.

I updated the patch to exclude Math as well. We checked ~20 repositories, so I think there are not too many more repositories with issues.

In T377197#10232445, @abi_ wrote:

Blocking us from merging patches in Translate repo. Example: 1073319: Special:ManageMessageGroupSubscriptions: Create page | https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1073319

We now have a different issue. The jobs seem to end with "Recording job details...", see https://logstash.wikimedia.org/goto/e0751daab837922c109a1c801c084ec3

Re-opening, as I'm seeing this on https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-noselenium/46335/consoleFull#console-section-18 for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1073319

Nevermind, the core patch linked with the GrowthExperiments one is wrong https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1077357/16/autoload.php (h/t @Reedy)

The problem is that we assume that user_name will be set, but for account creations (and autocreations), AbuseFilter sets a value for accountname instead. I'll make a patch to update AbuseFilterExamine.php and SpecialAbuseLog.php to fallback to accountname if user_name is not set.

Moving back to in progress, to add a dashboard panel once we have data.

Moving to "In progress" to add the panel once we have collected some data.

We need some more time to finalize the access policy and proposed changes.

In T326940#10227911, @kostajh wrote:

As far as I can tell, the only potential concern is in the pagequality permission, which allows for interacting with the tool. That is granted to the user group by default in GroupPermissions in extension.json. For all wikis except dewikisource, this remains as user. For dewikisource, the value is * meaning that temporary accounts would be able to interact with the tool.

As far as I can tell, the only potential concern is in the pagequality permission, which allows for interacting with the tool. That is granted to the user group by default in GroupPermissions in extension.json. For all wikis except dewikisource, this remains as user. For dewikisource, the value is * meaning that temporary accounts would be able to interact with the tool.

In T375086#10218765, @Niharika wrote:

@mszabo Legal wants us to update the access policy for IP Info before the changes in this task go live. I'm going to work with them to update the policy but it may take some time. In the meantime feel free to keep working on this task but hold off on merging any changes into master.

Soft depends on T376132: Set known flag for temporary accounts config on metawiki.