I have to leave now, but the core of this task is pretty simple:

Is there a majority to create tickets for the two bold statements (pun intended)?

I created T235763: Investigate broken Wikidata Bridge Storybook updates for looking into the broken storybook further.

We should be able to find a configuration that works for us, instead of us working around the tool chain we picked to help us.

Same problem here, I couldn’t get it to work (using jsub didn’t help either). For now I’d hope that it’s a temporary problem with Toolforge, and retry later?

Can be verified via Grafana once it’s deployed.

Shouldn’t this go into the Verification column for UX to review the button?

That’s a possible workaround, of course, but it causes additional network traffic and server load.

South of, I assume – that is, only the content excluding the header should be scrollable.

In MediaWiki core, uneditable pages display two messages: permissionserrorstext-withaction, the generic “you can’t edit this”, and then protectedpagetext or blockedtext (and cascadeprotected in case of cascade protection) with parameters detailing the cause. We should do something similar in Data Bridge, but with bridge-specific messages. The messages should also be read from the client wiki, not the repo wiki, so they can be customized via the MediaWiki namespace. @Charlie_WMDE and @Lydia_Pintscher will define the initial content of those messages, based on the MediaWiki versions, before the next story time (2019-10-22).

This never went anywhere, and I don’t think it’s really needed anymore – we’ve heard through other means that there are external users of the constraints API, so treating it as a stable interface really is the right thing to do. Closing.

Four PHP entry points left in production:

Now the script itself has been removed from mwlog1001, it seems.

I couldn’t figure out how to make it part of the app module, but extracting the dispatcher into a separate module reduces the size of the init module substantially:

Okay, https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php72-docker/24694/consoleFull has progressed far enough to see the effect of this build. There’s still some logspam due to the existence of the core-js postinstall script –

Thanks, I’ll try to find some Wikibase build to trigger.

@Evilricepuddin workaround: in

Ah, thanks – in that case, the method was introduced in I0605e725c4 to fix T172113: ConcurrentModificationException on non-grouping query with aggregates in SELECT.

Possibly related to @Igorkim78’s work in T168876: MWAPI service throws “could not find binding for parameter” if optimizer is not disabled? I306907e175 mentions that class, at least. (The upstream version of StaticAnalysis doesn’t have a collectVarsFromExpressions method, by the way, so I’m not sure what version of the class we’re using and what repository it’s in.)

Note: the migration was finished in https://gerrit.wikimedia.org/r/514508, which was not attached to this task. (Also, the PHP entry point is still used in production, but I figure it’s not worth reopening this task for that.)

(it was rather more than one line, especially when including the changes it required in other commits)

The discussion in T231209 assumes that we do this via JS, by checking mw.config.get( 'wgIsProbablyEditable' ). But I think we can do this via CSS, depending on the mw-editable class on the surrounding body (added in T208315) – that CSS could either be part of the init module, or be added PHP-side so it doesn’t even have to wait for ResourceLoader. I think this would be more efficient and better for the user (no flash of unhidden edit buttons before we get around to hiding them).

Good point – perhaps we can build another commonjs bundle and include that in the app ResourceLoader module.

In T235037#5572681, @Lucas_Werkmeister_WMDE wrote:

This should already be enough to unblock T235038: Read RepoConfigRepository in bridge init action and store config, though.

In principle, I think we could read the configuration asynchronously, just like we read the property label asynchronously, and update the input’s maxlength once we know it. But once we implement T235154, we’ll probably want to combine the API calls, and those ones should definitely be blocking, so we might as well make this blocking as well. It shouldn’t take too long anyways, hopefully.

The above change only implements part of this task – the rest is blocked on T235036: Implement RepoConfigRepository via wbdatabridgeconfig API. This should already be enough to unblock T235038: Read RepoConfigRepository in bridge init action and store config, though.

Note: the above change is only on master, not on 1.35.0-wmf.1, so banwiki will exist without localized Scribunto strings for a few days, if I’m not mistaken.

As pointed out in the Gerrit comments, $wgWBCitoidFullRestbaseURL still needs to be set (most likely to http://en.wikipedia.org/api/rest_) to fully enable Citoid integration on Test Wikidata.

And this version of the link only shows the past 5 minutes and auto-updates itself every 5 seconds:

This is problematic though, as that database would not be part of Wikimedia production and therefore cannot be accessed from another wiki directly.

Some parts of the config might also be useful elsewhere.

Yeah, I think there’s some off-by-one errors in the dictionary line selection:

But it looks like RandomImageGenerator::getRandomFilenames() always generates file names from a pair of words, e. g. foo_bar.jpg.

The above patch removes the fibers dependency completely, hopefully that works better on newer node versions – can one of you try it out?

Seems to be working on Beta.

In T233395#5509270, @Michael wrote:

Story writing remark: This may need an investigation as to why we are currently not getting more specific edit summaries. Shouldn't there be a diff happening on the server side?

Side note: the link is a bit broken anyways at the moment… it links to Wikidata’s Help:Property constraints portal/constraint item ID, and there are redirects from the item IDs to the real documentation subpages, but that only works when the same constraint item ID as on Wikidata is used – for example, on my local test wiki, the “format constraint” item is Q251, so the help link sends me to Help:Property constraints portal/Q251, which doesn’t exist. I suppose fixing that is out of the scope of this task, though.

Yeah, I noticed while working on the above patch how little this actually has to do with the API sandbox itself :)

Hm, this is a bit tricky because there’s some correspondence between “this module is deprecated” (make isDeprecated() return true) and “the parameter value specifying this module is deprecated” (ApiBase::PARAM_DEPRECATED), whereas there’s no such thing as internal parameter values. I’m not yet sure if that’s a big problem.

The 'internal' flag isn't available when building the list. You'd have to adjust the output from action=paraminfo for submodule-type parameters to somehow include it.

Unless someone has a better suggestion, I’d display internal modules similar to deprecated ones: ordered at the end of the module list, strikethrough on the label, and with a bold red notice before the summary message. (If we’re feeling adventurous, make the notice yellow instead of red?)

Depends on whether submodules can be marked as internal, though.

Looks okay on Beta now.

Moving to verification for checking if the setting is true on Beta, once the automatic sync has deployed the changes there.

…though they might not necessarily know what to do with it :)