| Cparle | |
| Feb 26 2019, 5:43 PM |
| F28521214: Screen Shot 2019-03-30 at 9.40.32 AM.png | |
| Mar 30 2019, 4:49 PM |
| F28521208: Screen Shot 2019-03-30 at 9.39.52 AM.png | |
| Mar 30 2019, 4:49 PM |
| F28521262: Screen Shot 2019-03-30 at 9.46.20 AM.png | |
| Mar 30 2019, 4:49 PM |
| F28521254: Screen Shot 2019-03-30 at 9.45.33 AM.png | |
| Mar 30 2019, 4:49 PM |
| F28521276: Screen Shot 2019-03-30 at 9.48.07 AM.png | |
| Mar 30 2019, 4:49 PM |
| F28521265: Screen Shot 2019-03-30 at 9.46.20 AM.png | |
| Mar 30 2019, 4:49 PM |
Make sure federation works on beta
Make sure config is setup correctly, and everything works
Acceptance criteria:
On a File page
| AC | Status | Details |
| 1 | ✅ | T217157#5071910 |
| 2 | ✅ | T217157#5071910 |
| 3 | ✅ | T217157#5071910 |
After talking with cormac on IRC, as far as I can tell federation is working just fine.
However search (backed by cirrus) does not take federated entities into account at all.
Erm ... 'working fine' might be over-egging it a bit. We haven't definitively shown it's *not* working, because some of the searching stuff doesn't seem to be right. Still looking into it ...
Ok for now what I'm gonna try is have the File page call wbsearchentities on wikidata instead of on commons. We shall see ...
Change 494996 had a related patch set uploaded (by Cparle; owner: Cparle):
[mediawiki/extensions/WikibaseMediaInfo@master] Configurable url for wbsearchentities queries on File page
Change 495256 had a related patch set uploaded (by Cparle; owner: Cparle):
[operations/mediawiki-config@master] External api url for wbsearchentities api call on commons
Change 494996 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Configurable url for wbsearchentities queries on File page
Change 495256 merged by jenkins-bot:
[operations/mediawiki-config@master] External api url for wbsearchentities api call on commons
Change 495282 had a related patch set uploaded (by MarkTraceur; owner: MarkTraceur):
[operations/mediawiki-config@master] Fix typo in config variable
Change 495282 merged by jenkins-bot:
[operations/mediawiki-config@master] Fix typo in config variable
Change 495666 had a related patch set uploaded (by Cparle; owner: Cparle):
[operations/mediawiki-config@master] Fix syntax for MediaInfo depicts config
Change 495666 merged by jenkins-bot:
[operations/mediawiki-config@master] Fix syntax for MediaInfo depicts config
@Cparle could use some test steps/acceptance criteria on this one, as it isn't immediately obvious :)
The ones @Cparle has added to the task description looks pretty good, and for the file page it might be it.
A list of possible further things to check, admittedly often not that end-user-facing ones. I'll let @Cparle and @Ramsey-WMF decide which of these deserve to be promoted to "acceptance criteria", and which are just things to test the verify that all works (tm).
(list not claimed to be complete)
When given Q-id or P-id as a search term to beta commons' wbsearchentities API, the API returns search results matching the item/property from beta Wikidata
This won't work, as the local search index doesn't contain wikidata items. We think this is ok, because we can (and do) call wbsearchentities on wikidata directly from commons
Special:NewItem and Special:NewProperty does not allow creating new entries on Beta commons
Both of these cause fatal errors atm :( Is there any way of disabling the pages? @Jdforrester-WMF @Addshore I seem to remember ye having some discussion about disabling special pages before?
No. Such functionality would have to be engineered into the labyrinth that is Wikibase itself. That's beyond me, and the Wikidata team haven't prioritised it at their end (which is fair, we want federation more than clean-up).
Documenting discussion in stand-up: Fixing the Special:NewItem and Special:NewProperty is not within our capability and will have to stay as is (with the fatal errors), which is not bad. These aren't pages users should be going to anyway, and this isn't a big deal for the short term.
Sorry, my bad, I forgot it is determined by Wikibase itself only when non-ElasticSearch search is used. @Addshore reminded my on the solution applied on Commons, which you also mentioned, so this point also seems to be fine!
Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome
Test Artifact(s):
On a File page
