We should also check if the same is the case for creating new Properties and Lexemes. I assume yes.

NewProperty fails with a clear permission error because the action is not enabled for anonymous users on beta. But that may not be the case for all installations - trying the same on a local development wiki creates the stack trace again.

whereas NewLexeme fails with an alert:

In T354730#9449572, @ArthurTaylor wrote:

NewProperty fails with a clear permission error because the action is not enabled for anonymous users on beta. But that may not be the case for all installations - trying the same on a local development wiki creates the stack trace again.

Thanks!
There could conceivably be Wikibase instances where Property creation is not restricted so we should probably check this still.

This may be related to T349130 - see also a WIP patch from @Tchanders https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/966585/

In T354730#9458861, @ArthurTaylor wrote:

This may be related to T349130 - see also a WIP patch from @Tchanders https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/966585/

That patch is now pretty far out of WIP (edit: I’ve now attached it to this task as well), and due to the way it’s implemented, it also seems to work for special pages even though it mostly focuses on the API:

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

[mediawiki/extensions/Wikibase@master] Add temporary user support to most API modules

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

Picking this up into our “sprint” board, since I’ve already been working on it for the past few days. I think we’re pretty close to a mergeable version. (Note that this will not cover all API actions – merging / redirects will need a bit more work.)

Change 966585 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add temporary user support to most API modules

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

The Gerrit changes got merged, but it’s still not working:

The action you have requested is limited to users in one of the groups: Users, Temporary users.
Permission error

I think this is because the Beta config is outdated and hasn’t been updated for the recent-ish(?) change where we still expect $wgGroupPermissions['*']['edit'] to be true.

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

[operations/mediawiki-config@master] beta: Don’t prevent * from editing if IP masking enabled

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

Change 992400 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: Don’t prevent * from editing if IP masking enabled

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

Now it’s working: https://wikidata.beta.wmflabs.org/w/index.php?title=Q627069&diff=prev&oldid=1355299&title=Q627069&diffonly=1

I was able to create an item in Special:NewItem with a temp user as seen as below. All browsers had similar results. This will be moved to Done. Thanks for all your work!

Status: ✅PASS
Environment: Wikidata Beta
OS: macOS Sonoma 14.2.1
Browser: Chrome 120, Firefox 121, Safari 17.2, Edge 120
Skins. Vector 2022
Device: MBA M2
Emulated Device:: n/a
Test Links:
Chrome: https://wikidata.beta.wmflabs.org/wiki/Q627105
Firefox: https://wikidata.beta.wmflabs.org/wiki/Q627104
Edge: https://wikidata.beta.wmflabs.org/wiki/Q627103
Safari: https://wikidata.beta.wmflabs.org/wiki/Q627102

✅AC1: https://phabricator.wikimedia.org/T354730

Create Item	WikiData	View History	Comparison

Is a Product-reproducible issue - let's have Product verify it.

An alternative: Redirect user to login wiki when the user click edit, so user will have a temporary account when they are in the edit mode. Though (1) this will results in temporatry accounts with zero global activity and (2) this does not handle users who lost a session in edit mode.

Don’t redirect at all. In that case, “your temp user identity will be irrecoverably limited to that single wiki” (@Tgr).

I suspect this won't be popular for attribution and patrolling purposes, and it's not something we're recommending elsewhere.

I realise your team will want to figure this out, but for what it's worth, 1D sounds sensible to me:

Stash the other edits client-side (localStorage or similar).

I believe Editing-team and Community-Tech have done some work on autosave, in case it would be helpful to speak to them.

But there’s a risk that the user will close the tab before finishing all the edits, and then the redirect never happens.

Maybe we could build some way of tracking whether the session has been "merged" into a central session, and force a central login at the next opportunity if that isn't the case. Though it wouldn't help if they close the tab and then go to another wiki next. Also the way CentralAuth works, the "remember me" flag (which makes logins expire after a year, instead of after a day) is only set during central login - I'm not quite sure if that's the case for temp users, who are logged in locally in a special way, but we should check. If it does affect temp users then the UI messaging about the temp account after the edit will be very misleading.

There is also a chance that T348388: Use central login wiki for login (SUL3) will find a way to make central login in the background work, and then this would become a non-issue. I wouldn't bet on it though.

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

[mediawiki/extensions/Wikibase@master] Use onTempUserCreatedRedirect hook in redirecting special pages

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

In T354730#9509749, @Lucas_Werkmeister_WMDE wrote:

For interactive edits using the API, I’m not even sure what the UX should be.

@Lydia_Pintscher, @ArthurTaylor and I discussed this situation now. Lydia said that, for new visitors who have never edited before, the situation of editing several data entries on the item at once should be quite uncommon; Arthur also pointed out that we can always add disabling other edit buttons later if we want. So we decided that:

• For normal edits (mainly statements), just redirect away after the API request. (Option 1A above.) In practice, it should be quite rare for this to result in data loss.
  • If we get enough complaints, or otherwise see the need, we can later disable edit buttons for anonymous users after they start their first edit (Option 3 above). We also discovered that DiscussionTools does this even for logged-in users and regardless of IP Masking status – but we know that our power users would object if we did it for everyone.
• For the legacy termbox, which makes a bunch of edits in rapid succession after clicking a single “save” button, redirect away after all those edits are done. (This is basically option 2 above, but with the difference that we’re not waiting for an indefinite amount of time until the user is done – we just wait until we’re done making all our API requests.)
• The new mobile termbox (aka Termbox v2 and other names) makes a single edit, so we can redirect away just like for normal edits.
• Option 4, not redirecting at all, is rejected, at least for code we’re responsible for. (WikibaseMediaInfo currently chooses this path, but should probably use one of the other options.)

Change 995260 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use onTempUserCreatedRedirect hook in redirecting special pages

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