As of MW 1.38+, mw.messages now supports the {{SERVERNAME}} magic word.
https://www.mediawiki.org/wiki/Manual:Messages_API#Feature_support_in_JavaScript
It was always our intention to include that magic word in the question, in order to improve clarity about the scope of the question.
We need to add it back in before we roll out the survey to other projects.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T294890 [EPIC] Configure and deploy safety survey | |||
| Resolved | jsn.sherman | T303769 Return {{SERVERNAME}} to GDI Safety Survey question now that it is supported in mw.message |
Event Timeline
Comment Actions
Change 770578 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):
[mediawiki/extensions/WikimediaMessages@master] Update question for the GDI safety internal survey
Comment Actions
Change 770578 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] Update question for the GDI safety internal survey
Comment Actions
@mepps... I am not for sure why you moved this to QA... There is no way for me to verify this fix from a QA standpoint... And also according to https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/770578/ its showing a status that the Post-merge build failed.
https://integration.wikimedia.org/ci/job/mwext-phpunit-coverage-docker-publish/54400/console : FAILURE in 1m 15s
So I am moving this ticket back to Review status.
Comment Actions
Hey @Djackson-ctr, I just wanted to speak to the post-merge build status in particular: that's a CICD foible of this repository that happens on every merge; it's not indicative of a problem and doesn't block deployment.
Comment Actions
@jsn.sherman thank you for explaining that status... Thats good for me to know for future reference, so going forward anytime I see that status with our tickets I will ignore it... Thanks again for the explanation.
Comment Actions
@mepps and @Djackson-ctr I created a bit of a problem here, as I was trying to slip a change in under the wire, with the intention of making it quick and easy. I really wasn't thinking about how qa could work when I did that. I think the safety survey is now undeployed from beta, so we can't really qa it there as things stand.
@mepps, there a few paths forward that I can see:
- we could skip qa on this change, since the only change is the addition of the magic word, which I verified with the current production version of mediawiki running locally. Obviously that does leave us exposed to some risk, because many a dev has uttered "it worked on my machine" with their dying breath
- In my absence, Susana could stand up a demo for it, and we could qa against that
- We could let it sit until I get back, and I could learn how to set up one of those demos or add the safety survey back in to fa beta.
- If we deploy the new survey configs to beta, this would be a straightforward check to add on to those
Comment Actions
Change 770997 had a related patch set uploaded (by Mepps; author: Mepps):
[mediawiki/extensions/WikimediaMessages@master] Update internal trust and safety survey question for testing
Comment Actions
Change 770997 merged by jenkins-bot:
[mediawiki/extensions/WikimediaMessages@master] Update internal trust and safety survey question for testing
Comment Actions
@mepps, @eigyan, @aminalhazwani, @Scardenasmolinar:
I have discovered 2 defects involving mobile devices in which the X (to exit/close the survey) has been pushed outside the boundary/border of the survey or the X is not displaying on the survey, below are screenshots of the defect...
From my point of view we have never had this type of screen layout issue before now (other than Susana's fix for the padding issue T296482
[Bug] Additional horizontal padding displayed in QuickSurvey on mobile devices that has already passed QA testing)...
So the obvious question is this defect related to the fix for T296482, OR another obvious question could be that this defect is related to the addition of the servername fix that is causing this issue OR could the issue be caused by the long servername (en.wikipedia.beta.wmflabs.org) OR could the issue be caused by something totally different/unrelated to any of the above that I just mentioned?
In the meantime I am going to push this ticket back to Review/Feedback on our workboard.
When using Samsung FE 20 phone with Android Version 12 (Portrait orientation) / Apple iPhone 13 Pro Max with iOS version 15 (Landscape orientation) the X is pushed outside the boundary/border of the survey:
When using an Android version 12 Google API phone emulator (Portrait orientation) the X is not displaying on the survey:
Comment Actions
I don't know if this can be considered related to the this exact ticket (probably not), but what happens from my understanding is that long (non-breaking) text pushes the close button out of the bounding box. This still happens also if I revert the changes that @Scardenasmolinar did for the T296482.
Comment Actions
After speaking with the team regarding the defect, it has been decided that a bug will be filed for the issue regarding the X button being pushed outside the boundary/border of the survey...
As for this specific ticket (T303769) since no other issues were found that effected the functionality or behavior of the survey, then this ticket will be pushed to Product Sign Off.
Below are some screenshots of new code change(s):
(NOTE: please disregard blurriness of screenshots, this is due to device simulation and is not related to the code changes):
