One way to approach this is via endpoints. That includes on the repo side:

• Wikibase Action-API endpoints, such as wbeditentity
  • question to answer: how much is this generalized? How much is this endpoint-specific
• Special pages, such as Special:NewItem
  • what message is shown, should it be shown differently?
• The JS UI anon editor warning
• how/where exactly is semi-protection of pages handled?
• What does this mean for Lexeme?
• What does this mean for WikibaseQualityConstraints?
• What does this mean for EntitySchema?
• ...

Another approach is to look at the code, find what methods/patterns are used to distinguish between logged-in and anon users, and then look all the places where these are used.

Also relevant, but potentially out of scope:

• How is the new Termbox handling anon users?
• How is the REST API handling anon users?

First observation:

Using a local config based on a related core change looking as follows:

$wgAutoCreateTempUser = [
	'enabled' => true,
	'actions' => [
		0 => 'edit',
	],
    'genPattern' => '*Unregistered $1*',
    'matchPattern' => '*$1',
    'serialProvider' => [ 'type' => 'local' ],
    'serialMapping' => [ 'type' => 'plain-numeric' ],
];

1. Editing a Statement on an Item through the UI while not logged-in did NOT create a new temporary user and instead recorded the IP address.
2. Editing an ordinary Wikipage however, did create a temporary user.
3. Using that temporary user, it was then possible to make an edit to a Statement via the UI that shows in the history with the temporary user instead of the IP.

Creating a new Item did also NOT result in a temporary user being created.

Neither creating an EntitySchema via Special:NewEntitySchema, nor edits to the schema text (action=edit) triggered the creation of a temporary user.

NewItem, NewProperty, NewLexeme, NewEntitySchema, all of them do NOT show the "anon-user-warning" to temporary users.

The code that used to check for this is currently \User::isRegistered() (or \User::isAnon(), which is just the negated result of the former).

Since 1.39, Mediawiki also has the methods \User::isNamed() and \User::isTemp(), which might be suitable for what we maybe want to do.

EntitySchema seems to be the only Extension of ours that uses \User::isAnon():
https://codesearch.wmcloud.org/things/?q=-%3EisAnon%5C%28%5C%29&files=.*%5C.php&excludeFiles=&repos=Extension%3AEntitySchema%2CExtension%3AWikibase%2CExtension%3AWikibaseLexeme%2CExtension%3AWikibaseQualityConstraints
It is used to show the anon edit warning.

There are two more ways to edit EntitySchema: undo and restore. Neither of those has the anon edit warning, and both trigger the IP Address to be recorded, without an anonymous user being created.

Special:MergeLexemes and the non-js fallback of Special:NewLexeme use User:isRegistered() for showing the anon user warning. The Vue-based Special:NewLexme page gets that information for the same purpose via js: mw.user.isAnon().

On the js side of things, there seems to be both mw.config.get( 'wgUserIsTemp' ) and mw.user.isTemp().

TODO NEXT:

• look at the client entry and the UpdateRepoJob.php entry for https://codesearch.wmcloud.org/things/?q=-%3EisRegistered%5C%28%5C%29&files=.*%5C.php&excludeFiles=&repos=Extension%3AEntitySchema%2CExtension%3AWikibase%2CExtension%3AWikibaseLexeme%2CExtension%3AWikibaseQualityConstraints
• for completeness sake look at isNamed and isTemp, both in js and php
• look at $user-getId() != 0
• look at client from the other side, include what is mentioned in T343800#9077730

(ca. 4.5 hours done so far)

Looking at \User::getId did not result in any places in Wikibase+ that would have different behavior based on logged-in status.

As far as I can see, this should cover all the cases I found in a first pass. I think there are about 2 hours left in the timebox for some more in-depth investigation, if needed, or for a nicer write-up of the findings, if that is desired.

Regarding Wikibase edits not auto-creating temporary accounts: In MediaWiki core, this seems to happen in EditPage::maybeActivateTempUserCreate() and EditPage::createTempUser(); I imagine we’ll need similar code in either MediaWikiEditEntity or WikiPageEntityStore, not sure which.

Also, as seen in T343799#9077216, $wgAutoCreateTempUser supports different actions, with edit currently being the only known action; I think we should check with the MediaWiki core developers whether Wikibase should also use this edit action (interpreting it as a very generic term) or use one or more different, Wikibase-specific actions (“wikibase-edit”? or even one per API module / special page?). (Edit: now asked at T326816#9122653.)

In T343799#9110430, @Lucas_Werkmeister_WMDE wrote:

Regarding Wikibase edits not auto-creating temporary accounts: In MediaWiki core, this seems to happen in EditPage::maybeActivateTempUserCreate() and EditPage::createTempUser(); I imagine we’ll need similar code in either MediaWikiEditEntity or WikiPageEntityStore, not sure which.

I’m now leaning towards WikiPageEntityStore, so that it also applies to ItemMergeInteractor.

See also T336187: [S] Investigate: Creating temp user on non-EditPage actions for some useful guidance.

the jquery.Ui LinkItem widget is only shown to registered users and not Anonymous IPs. However, it _is_ currently shown to temporary users.

See: T140661: enable add links widget for anonymous users

Thank you! Looking good. Moving this to tech verification.

While it is good to have all the history here on the ticket, and the results in the ticket description, phabricator is not an ideal place for future discoverability and I would prefer if you summarized the entire investigation in one place that is easily searchable (for example on wiki or in a google doc), for posterity.

To me, Phabricator feels more searchable and keeping things in their context than Google Docs, but a Wiki sounds like not a bad idea. We should be using wikis more anyway. Now I'm wondering which wiki would be best? Probably either www.wikimedia.org or wikitech. I will ponder it some more and find a suitable place.

For Mismatch Finder, we used Wikitech for any documentation that relates to Wikmedia specific infrastructure: https://wikitech.wikimedia.org/wiki/Tool:Wikidata_Mismatch_Finder

We also have a Wikdata page there that I have slowly started to restructure and add to: https://wikitech.wikimedia.org/wiki/WMDE/Wikidata

So I would prefer for Wikitech to be our team's one-stop shop, if we go for onwiki documentation.