Claiming this to implement an updateSchema method

Which version of the docker images are you running? e.g. 1.31/1.32...?

Looks like maybe this is now "done"? given that we have a single user case for creation and we think we don't need others?

This turned out to be more than 1k lines of code not including tests. We decided not to use this in favour of taking a lighter weight approach.

back to ToDo since it looks like the undo chain will be v. different

+1 mediawiki/TranslatableComments

I was initially drawn towards just leaving the Wikibase thing and using the hook in our own way. (Option 1 from @Michael)

For restore:
The restore link in the item history take you to a diff page (nicely formatted)
There is a publish changes button
This takes you back to the view item page
message in history looks like: Restore revision 424510 by 10.68.16.199

To get some more details I tested on https://test.wikidata.org/w/index.php?title=Q177525

While we're in this very early development perhaps we can even just nuke the DB's and start clean without the legacy update stuff?

Or finally you can turn of MW session handling with

define('MW_NO_SESSION_HANDLER', true);

Alternatively this is solvable by adding a delay to the requests made by mwbot with something similar to:

return new Promise( (resolve) => { setTimeout(  () => {
                resolve()
            }, 1000 ) } ).then( () => {
                return this.rawRequest(requestOptions)
            } ).then.........

node_modules/mwbot/src/index.js:248

@Addshore and I dug into this today.

Github Nuked

Entry in RC leads you to a diff page
Also entry has to be formatted in some way. I.e. not just O1232345 but something human readable

So, after talking to Lydia clicking to a different page to edit isn't really acceptable. This is because it breaks the user experience that people are used to e.g. with visual editor / normal entity editing on wikidata

They need to know the id first because otherwise they can't know what to paste into the box because the shape expression needs the id

Is it a human-readable discussion? If yes why not use talk page?

We are experimenting with writing our user stories in a way that is more decoupled from the implementation details that before.

Patches are up; needs review and then possible deployment

No problem. So the 'only' issue is that the boxes aren't correctly pegged to the field you should be working on when doing the tour?

I could replicate the 'failure to attach' behaviour.

Mostly fixed but still some failures:
https://integration.wikimedia.org/ci/job/mwext-php70-phan-docker/19248/console

Teh patches are there because From IRC:

CI blocked hence UBN :(

This is now unstalled since 1.32 is available at https://wikidata-shex.wmflabs.org

In the absence of complaint I'll probably make one on 'wikidata-dev' since that seems the perfect place

Cool, any objections to putting it on a cloudvps project? Do we have a WMDE dev one that could be repurposed?

I've asked @Addshore if he can do this for us.

In T211568#4873003, @Addshore wrote:

In their current state the patches enable the creation and approval of an OAuth consumer.
However the user needs to be allowed to "mwoauthproposeconsumer" and "mwoauthmanageconsumer".

@Tarrow do you think that is okay for our usecase?

From wmf-config/InitialiseSettings.php:

'wgWBQualityConstraintsTypeCheckMaxEntities' => [
	'default' => 1000,
	'wikidatawiki' => 100,
],

It does not appear that deploying this patch without parser cache invalidation will cause cause frontend JS breakages.