As an editor I want to be able to use an API and SpecialPage that gives me an overview of all violations for a given item so I can assess and fix all issues. The distinction between internal and external violations is almost an implementation detail in this usecase.
Description
Description
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Resolved | Lydia_Pintscher | T97018 [Story] Integrate violations into Wikidata UI | ||
| Declined | None | T110039 [Story] Unified API and SpecialPage for internal and external constraint violations | ||
| · · · |
Event Timeline
Comment Actions
Discussed during story time:
- Have an "wbcheckentity/wbvalidation" (?) API. It does the checks in real-time.
- Create a new [[Special:{All|Combined|Full}ConstraintReport]] (?) including external constraints, in addition to [[Special:ConstraintReport]]. Or repurpose the existing one.
- Have a button in the UI, added via the extension (probably the base WikibaseQuality), that triggers that API call and adds icons to all statements with a violation. To do: Check the ditched version 2, relevant code should already be there.
- No-JS fallback for the button: Link to the new special page.
- Implement a caching layer for the results. (Note: The students working on Wikibase-Quality-Constraints worked on a branch implementing persistence, but this got stuck on review and we had to ditch it.)
- Trigger checks/purge during save. Warning: Need to purge all items using a property when the property is edited!
Keep in mind:
- In the future more external tools may want to add annotations/icons to our view (see T95403).
Comment Actions
With the way WikibaseQualityConstraints has evolved since task was opened, I don’t think there’s any point in keeping this open. If we pick up external validation again, we can decide whether it makes sense to integrate it with constraints or not. (But note, for example, that the special page is not the primary way in which users interact with constraints.)