Accesskey and title tooltip are now restored.
lowering the priority as the expected fixed landed on group1 wikis. This should no longer block the train. The task will be closed once we've confirmed there are no issues discovered as the train proceeds.
Random question, maybe you'd be in the know @Ladsgroup: any chance we could get the past missing data back-filled?
During Wikidamania @EBjune and @RazShuty have agreed on accepting the risk as assesed by the Security Team. I take that due to its nature, the communication about the further steps will be handled by email mostly (as has happened so far).
I am letting unstalling and other changes of the status of this ticket on the discretion of WMF Security team.
Fair point, will adjust the description.
We just spoke in the office and it seems that the decision (as I heard it from @WMDE-leszek and @Lea_WMDE) is to remove currently invalid language even from historic revisions. We won't change the database but we will stop showing any invalid language. e.g. from API requests, in the UI (perhaps in non-XML dumps?), in Special:EntityData, in ttl etc..
They will perhaps be reintroduced after T225789 is done once what we will do is decided upon.
Likely to have been solved already. Close as resolved if not found in the logs from last 2 weeks.
For starters, to investigate: find out in what situations (what API endpoint, what kind of edit request) those errors have happened in the last ~30 days.
Time to spend on investigation: 4 hours.
If we want to reference specific images in the docker-compose.yml file, we could already do that using the image hash.
Fri, Aug 16
Thu, Aug 15
Thanks @dom_walden. We'll fix this. Also I've updated your admin rights on beta wikidata so they wouldn't expire.
Verified on test.wikidata.org, closing!
@WMDE-leszek you patch is still WIP, are you still working on it?
All credit to @Rosalie_WMDE, she fixed it all! I was just a messenger.
Wed, Aug 14
Thanks @Lejonel for paying attention to details. Typo in the CSS class is fixed in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/530146/.
I am looking into the accesskey issue next.
Tue, Aug 13
Following up quickly the comment above: Per https://test.wikidata.org/wiki/Special:ListUsers?username=&group=interface-admin pinging @Pasleim @Ladsgroup @Rosalie_WMDE: maybe you folks could help with bring changes linked in https://phabricator.wikimedia.org/T223999#5402050 to test.wikidata.org ?
@Mrjohncummings @NavinoEvans we've made some changes, which should hopefully help. I am not able to bring the changed files to test.wikidata.org due to lack of permissions. Would you mind try it yourselves? See the github gist linked T223999#5402050
Correction to the above. This is indeed done. The change which made it is https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/480548/ though
Mon, Aug 12
Yes, the very https://github.com/wmde/wdio-wikibase :)
Also, is checking in package-lock.json file is the practice we've agreed on at WMDE? It does not seem to be there yet. Finally, having npm test do something would be nice.
Could we have a (simple is fine) README in https://github.com/wmde/wdio-wikibase?
Thu, Aug 8
Likely that'd be a configuration missing/incomplete. Looking into it
It seems there is no structured way to log client/browser errors to some MW's logging facility, so random brutal way to check log could be to check in the selenium test code if there are errors in the browser reported, and if so, dump them to test logs.
Wed, Aug 7
https://wikitech.wikimedia.org/wiki/WMDE/Analytics#analytics/wmde/toolkit-analyzer_repo_and_build seems to have some instructions
Tue, Aug 6
Mon, Aug 5
Closing per the discussion in the comments above.
@Ladsgroup: Have you had a chance to investigate the bypassing the parser cache? Any findings to share?