Storybook has been updated: https://tools-static.wmflabs.org/wikibase-databridge-storybook/?path=/story/initializing--default

We likely want to do the update flow in two edits to have useful edit summaries.

@Charlie_WMDE @Sarai-WMDE: We adjusted the global styles of the Storybook so that it should be by default closer to the OOUI Demo page. Could you verify this component again?

Yes, that file was created in context of T213726: Register Schema: namespace. I don't think it is needed anymore.

In T237527#5693196, @Michael wrote:

In T237527#5693170, @Lucas_Werkmeister_WMDE wrote:

Actually, let’s put this in verification. Can someone update the storybook? (See T235763 for instructions.)

Can do.

In T237527#5693170, @Lucas_Werkmeister_WMDE wrote:

Actually, let’s put this in verification. Can someone update the storybook? (See T235763 for instructions.)

We discussed that the investigation (T237522) uncovered that we currently cannot get the intended blockee from the mediawiki API. We decided that for now, we drop that requirement, i.e. that bullet point in the error message, and create a ticket to follow up later. See T238828: Show intended blockee in blocked message in wikidata bridge

Left todo: create the dashboards in grafana

Thank you for the links! I made Jenkins remember this log (thanks @Lucas_Werkmeister_WMDE for showing me how), and I'm prioritizing this higher, so we spend some time soon-ish in investigating what is going on.

Partial breakdown for now. We will have to break it down further.

This is unrelated to Wikidata Bridge, which is a feature still in early development.

@Jdlrobson I looked through recent MobileFrontend patches, but couldn't find a failure related to this task. Could you point us to a patch where it occurred?

Yeah, I later noticed that this config option seemed to be only active by default in the 69 beta, not in the actual release and wanted to investigate further, but didn't get around to it so far.
At least now we have enough time to get the implementation right without "loosing time" to Wikipedia being less performative than it could be on Firefox.

Added a quick implementation of the requested change. Though the specifics might depend on the decisions to the questions raised by Pablo.

So the idea is to only show the edit pens when the bridge is ready? That might actually work quite well 🤔

In T236235#5598946, @Lucas_Werkmeister_WMDE wrote:

I would suggest counter.MediaWiki.wikibase.client.databridge.datatype.string, for consistency with some other things tracked in Wikibase. (Note that the MediaWiki part is added automatically when logging from PHP, but in JS we have to add it ourselves.)

Maybe the topic could be something like counter.Wikibase.DataBridge.datatype.string ?

In T236235#5598552, @Matthias_Geisler_WMDE wrote:

Just a question regarding 3rd parties, which are not using Graphite. Do we make Graphite as a dependency now, or we wanna try to make this feature some how not effective if it's (Graphite) not enabled/available?

So far we only have a suggestion for a change in technology but no measurable success criteria.

@Charlie_WMDE I think this is ready to be verified on beta: https://de.wikipedia.beta.wmflabs.org/wiki/Data-Bridge

In T235055#5594302, @Charlie_WMDE wrote:

@Lucas_Werkmeister_WMDE @Michael
According to the inspector the button seems to have a height of 36.7px. would that automatically adjust itself to 40px when placed in the header? Because that's the height it would need to have in the end.

Even though the bug mentioned above indicates that the new LocalStorage should be available in Firefox 69, I would feel better if we were able to actually verify that.
However, I'm not sure how to do so. Any ideas?

From my initial thoughts it seems to make sense to start with storybook in the same repository for now. That should represent the state of the components at the tip of the master branch and facilitate communication from developers to UX.

This issue seems to be resolved in Firefox 69 and apparently the quota is now per origin. See: https://bugzilla.mozilla.org/show_bug.cgi?id=1064466#c18

Thank you, @Lucas_Werkmeister_WMDE, for making a current version of the storybook available again :)

In T235055#5580471, @Lucas_Werkmeister_WMDE wrote:

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

In T232468#5575133, @Charlie_WMDE wrote:

@Michael you have a very good point, thank you for voicing it. After talking to the UX-colleagues I think it's the best idea to stick to the 1second rule, but make sure that we always show the loading indicator for at least 0.5 seconds.
the idea is to always add 0.2 seconds fade in and fade out at the beginning and end of the animation, which would ensure we always get 0.5 seconds in the worst case (worst case being the 0.1 seconds).
Is that technically possible?

In T233305#5579153, @Lucas_Werkmeister_WMDE wrote:

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:

[...]
diff --git a/client/resources/Resources.php b/client/resources/Resources.php
index 9c9a0e0f2..085d2bccd 100644
--- a/client/resources/Resources.php
+++ b/client/resources/Resources.php
@@ -66,6 +66,24 @@
 			}
 		],
+		'wikibase.client.data-bridge.dispatcher' => [
+			'factory' => function () {
+				$clientSettings = WikibaseClient::getDefaultInstance()->getSettings();
+				return new ResourceLoaderFileModule(
+					[
+						'scripts' => [
+							'dispatcher.common.js'
+						],
+						'targets' => $clientSettings->getSetting( 'dataBridgeEnabled' ) ?
+							[ 'desktop', 'mobile' ] :
+							[],
+						'remoteExtPath' => 'Wikibase/client/data-bridge/dist',
+					],
+					__DIR__ . '/../data-bridge/dist'
+				);
+			},
+		],
+
 		'wikibase.client.data-bridge.app' => [
 			'factory' => function () {
 				$clientSettings = WikibaseClient::getDefaultInstance()->getSettings();

[...]

While working on this ticket a bug in @vue/test-utils was noticed and reported: https://github.com/vuejs/vue-test-utils/issues/1321
This bug could lead to falsely green tickets.

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).