Following a discussion with @Cparle, it seems clear we need to create a new temporary user when an anonymous user first edits structured data. This is an example of the need for T336187: [S] Investigate: Creating temp user on non-EditPage actions.

We're considering two approaches:

• The temporary user is created by the API endpoint, similar to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/954721/
• MediaWiki provides an API for creating a temporary user that can be called by StatementPanel.js and CaptionsPanel.js

The first seems better to me, but I wonder if there's a general need for the second.

@matmarex As someone who has had to create temp users from a few different places (albeit action=edit), do you have any thoughts?

In T340540#9196051, @Tchanders wrote:

We're considering two approaches:

• The temporary user is created by the API endpoint, similar to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/954721/
• MediaWiki provides an API for creating a temporary user that can be called by StatementPanel.js and CaptionsPanel.js

The first seems better to me, but I wonder if there's a general need for the second.

The first also seems more natural to me. The second one would work as well, it just makes different tradeoffs.

The tradeoffs are:

1. With first approach, some logic has to be re-implemented in each API module: 1) accept "returnto" parameters 2) if logged-out, create an unsaved temp user at the start 3) use it for permission checks throughout 4) once you've checked everything and are sure that the action will go through, save the user 5) return whether a temp user was created, and the result of running the onTempUserCreatedRedirect() hook with the "returnto" parameters. However, a lot of this logic could probably be shared, using something similar to ApiWatchlistTrait.
2. With second approach, this logic only goes into the core API module, but you instead need to figure out some anti-abuse mechanisms for the core module (like adding rate limits and log entries) that aren't needed otherwise because we just rely on the action itself (e.g. saving an edit) already having them. It also would introduce a small change to IP masking concepts, as temporary users with no recorded actions could now exist. Also, you would need to perform two API requests client-side in order and combine their results, which can be annoying to introduce in legacy code (but not a big deal if you use standard promises or async/await in modern code).
3. With both approaches, you still need to change the client-side code in a similar way: if a temp user was created, it needs to redirect to the URL given by the API result to complete central login with the temp user name; when sending the API requests, it needs to set up the "returnto" parameters to allow the user to be redirected back to your interface; and once the user returns, it should show the user a confirmation that their action succeeded and that they're now using a temporary account. Implementing all of this was the most laborious part in my experience.

Overall, I would suggest the first approach, unless we discover that we have API modules that must support logged-out actions and for some reason absolutely can't be modified. The second approach may be slightly faster to implement, but it adds complexity for the users (patrollers) and in the site configuration.

FWIW the first seems more natural to me too.

Just want to make sure my mental model of this is correct:

• user clicks "edit" in the structured data tab on the File page
• they make a change and click "publish", which sends a request to a wikibase api endpoint
• client side code checks the "returnto" param, and if it's populated loads that page (which will in this case just be the File page the user is already on)

Is that about right?

Yeah, pretty much.

Change 983423 had a related patch set uploaded (by Cparle; author: Cparle):

[mediawiki/extensions/WikibaseMediaInfo@master] Inform the user is a tempuser has been created while they were editing structured data

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

@matmarex ... are we sure we need the returnto? Would the little 'temporary account created' popup suffice? If it would that simplifies things quite a bit

(I took the returnto part out of @Tchanders patch but I can put it back in if you feel strongly about it)

Ok the wikibase patch has been merged, so this is now ready for review

Note that:

• when a temp user is created as a result of structured data edits we don't immediately add the black bar on top the user interface - we just show a popup informing the user (and the black bar will be displayed when they reload or navigate away from the page)
• constraint checks are enabled for non-temporary logged-in users only

Change 983423 merged by jenkins-bot:

[mediawiki/extensions/WikibaseMediaInfo@master] Inform the user if a temp user has been created while they were editing structured data

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

Checked on commons beta.
When a first edit is a Structured data edit following the steps below( the steps are from @Cparle's comment on the task)

- user clicks "edit" in the structured data tab on the File page
- they make a change and click "publish"

the result is

• a temp user is created
• the black bar on top of the user interface is not displayed (as per this comment;
• the popup is displayed
• an edit is successfully recorded in View History, Special:Contributions, and on ReceentChanges

However, the black bar never appears - reloading a page, navigating away, and doing more edits don't result in displaying it. The toolbar has "Exit session" link though:

@Etonkovidova I get the same behaviour on https://de.wikipedia.beta.wmflabs.org/ ... maybe it's just beta?

In T340540#9641677, @Cparle wrote:

@Etonkovidova I get the same behaviour on https://de.wikipedia.beta.wmflabs.org/ ... maybe it's just beta?

Interesting - temp users handling is different on cswiki betalabs vs dewiki betalabs. I'll follow up on it, thx, @Cparle!

In T340540#9651090, @Etonkovidova wrote:

In T340540#9641677, @Cparle wrote:

@Etonkovidova I get the same behaviour on https://de.wikipedia.beta.wmflabs.org/ ... maybe it's just beta?

Interesting - temp users handling is different on cswiki betalabs vs dewiki betalabs. I'll follow up on it, thx, @Cparle!

@Cparle - this is due to the Vector Legacy skin being default for some wiki (including commons); there is a task - T339377: Provide temporary accounts banner for legacy Vector
The list of wikis with Vector Legacy deafault: https://noc.wikimedia.org/conf/highlight.php?file=dblists/legacy-vector.dblist

Change #1178877 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseMediaInfo@master] Only show constraint check results for actually logged in users

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

Change #1178877 merged by jenkins-bot:

[mediawiki/extensions/WikibaseMediaInfo@master] Only show constraint check results for actually logged in users

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