https://github.com/wmde/wikidata-mismatch-finder/pull/171

Merged and deployed to toolforge.

https://github.com/wmde/wikidata-mismatch-finder/pull/165

Very good choice indeed, just what I actually already set it to :-)

@Lydia_Pintscher do we have a maximum allowed length for the "external source" field? The description's max length is 350.

https://github.com/wmde/wikidata-mismatch-finder/pull/159

re-assigning for review and possible last changes

https://github.com/wmde/wikidata-mismatch-finder/pull/123

follow-up PR: https://github.com/wmde/wikidata-mismatch-finder/pull/125

https://github.com/wmde/wikidata-mismatch-finder/pull/118 and
https://github.com/wmde/wikidata-mismatch-finder/pull/122

Hit Enter too early. m(

https://github.com/wmde/wikidata-mismatch-finder/pull/121

Notes from task breakdown:

Notes from task breakdown:

added a comment to T290058, done.

As per the investigation task T290969, this should indeed be done as a second toolforge project

@Mattia_Capozzi_WMDE this is ready for re-testing an verification on https://mismatch-finder.toolforge.org/

https://github.com/wmde/wikidata-mismatch-finder/pull/116

nothing to verify on production in this tech subtask

After brief chats with @hoo and @Addshore the most obvious approach seems to be a second toolforge project for staging.

• The WD/WB teams do not maintain many (if any) tools on toolforge at the moment, so apparently there are no prior examples for this.
• The setup should be quite straightforward, because we'll be able to simply copy most of the processes we are running for prod already.
• GitHub actions will have to be updated for auto-deployment. Exact steps will have to be discussed. (e.g. deploy to production only after UX or product approval on staging?)
• When: probably any time.

This can be verified in prod using a browser extension such as ModHeader. Adding a custom HTTP header 'X-Mismatch-Results-Error' will force a server side error that allows testing the error message:

The json response from the backend is passed into the Results Page component and shown in a rudimentary table element that will be replaced in a subsequent PR: https://mismatch-finder.toolforge.org/results?ids=Q1234

This can only be tested/verified in dev environments at this point, wich is fine for a "tech task":

The Table component as well as corresponding tests have been moved to Wikit and tests are passing.

https://github.com/wmde/wikidata-mismatch-finder/pull/110

This fix could use some kind of test/verification.

Merged and confirmed to be working on main: https://github.com/wmde/wikidata-mismatch-finder/runs/3629618254?check_suite_focus=true

https://github.com/wmde/wikidata-mismatch-finder/pull/105

Notes from task breakdown:

• https://laravel.com/docs/8.x/dusk#running-tests-on-github-actions

Notes from task breakdown:

• Error message will always be displayed without a results table
• Note is the "Message" Wikit component

Notes from Task Breakdown:

• Figma design is still needed for the combined "Note plus results table" scenario
• Inertia response should trigger a flash message for Items that have no mismatches (see https://inertiajs.com/shared-data#flash-messages)
• add the logic to the results web route, possibly by moving it into a separate Controller
• Note is the "Message" Wikit component

Plan of action from task breakdown:

Notes from task breakdown:

https://github.com/wmde/wikidata-mismatch-finder/pull/102