next steps

• Product to provide clarity on the use-cases we're aiming to support
  • this would help us understand things like: how important is it for the query service to have the most up-to-date violation data? If a user visits an item page based on a query, is it a problem if violations don't agree, or is some lag expected/acceptable?
• Map out the requirements of the query service updater. We have assumptions about what it needs, and why ingestion of constraint violations was turned off. @mahmoud.abdelsattar.wmde will reach out to WMF and set up a meeting with someone who can walk us through it. @AudreyPenven_WMDE and @Lucas_Werkmeister_WMDE want to join that conversation

meeting notes:

the current situation

• WikibaseQualityConstraints
  • stores the results of its checks in a cache, and seemingly *only* in a cache. There is no guarantee about how long they remain in the cache
  • Constraints are queryable by item id or claim id using the wbcheckconstraints api. In this api call, it first checks the cache. If nothing is found (or out of date info is found? unclear to me) it performs checks for the specified items/claims and stores the results in the cache.
  • constraint checks are triggered by edits to an item and its statements
  • presumably constraint checks are also triggered by changes to constraint statements themselves on properties. For this to be complete, all statements for the affected property must be found and then checked.
  • there is also an api for checking the parameters of constraints: wbcheckconstraintparameters

Here's a screenshot of the current adjustment:

On further investigation, I found that add reference and add qualifier are the only modals using the "minimal" style. Since the changes to this style can be easily isolated, I've made a commit that sticks to the original scope of this ticket. The broader question about consistency for all modal headers can be handled later, if necessary.

hooray! moving it along now

In investigating this, I found that we have at least 2 ways of creating modal headers. The ones with too much padding ("add qualifier", "add reference", "add statement", "add value") are using the "header" slot in WikibaseWbui2025ModalOverlay.
The padding for these headers are defined as: padding: @spacing-250 @spacing-75 @spacing-150 @spacing-75; (resulting in 40px on top, and 24 px on the bottom)

Ahhh maybe not. A test failure on CI lead me to this commit in api-testing, which makes the config into a module object rather than a function.

Should we just wait and see what LibUp does in its next run then?

LibUp's config was updated yesterday, so now I'm confused about a couple things:

Of these options, 1 sounds the best to me. I agree that it makes sense to keep Wbui2025 logic out of random extensions.

The current version of api-testing locks supertest at "7.1.0", which I assume is why LibUp could not update it.
A patch to bump the dependency in api-testing is merged, but we'll need a new release of that before it is available.

There's an in-progress patch for this, with a css-only change. It works for musical notation, but is not ideal for long string values.

@ArthurTaylor mentioned in the parent task:

The task split looks pretty sensible, and we can go through in more detail when we do the task breakdown. The big concern I have is about the end-to-end testing - we would need a way to enable the Musical Notation datatype for Wikibase when the Score extension is loaded, and we would need there to be a live Shellbox for CI that has lilypond installed. I expect that both of these things will be hard to achieve with Quibble. We might have to make do with unit testing - still an improvement on the zero tests currently included in the Score extension.

makes sense! I'll add this context to T412141

spike notes:

• once the extension is set up correctly, existing statements with musical notation are displayed with some minor style issues for long values. Covered in T412128: [MEX] M4.1.10 Display statements with musical notation in view mode