Describe the Bug
When an external user accesses the docket record of one of their cases from their mobile device:
The document title is centered rather than on the left side of the mobile screen
Clicking on the document link of any documents on the docket record results in a blank white screen.
Business Impact/Reason for Severity
high
In which environment did you see this bug?
Prod, Test
Who were you logged in as?
Petitioner, Practitioners
What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.)
This bug was reported to us via a DAWSON Support ticket from a Petitioner attempting to view a document on their case.
To Reproduce
Steps to reproduce the behavior:
Log in as a Petitioner that has a case. Be sure that you log in on a mobile device. (Android or iOS)
Click on the link to the case from the My Cases Page
Notice that the document titles are centered, rather than on the left side of the screen.
Click on a document link on the docket record
You will experience a white screen
Expected Behavior
Logged in users should be able to click on a document link and view documents when using a mobile device, also, formatting of the document link needs to be consistent for all users when viewing the docket record on a mobile device.
Actual Behavior
Logged in public users experience a white screen if they click on a document link on a mobile device, and they cannot get out of it, they have to restart their session and log back in to DAWSON. Also, the formatting of the document title is different for public logged in users.
Notes
In looking at the Kibana logs, it would appear that this started happening after the 8/28 release. It may have something to do with the refactoring that was done in story #10106 with the mobile view of the docket record? Prior to the release, we see log entries of document downloads from users accessing DAWSON on mobile devices. If you would like to check this out in the logs as well, add a filter for request.headers.user-agent and then for Android devices add this: Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Mobile Safari/537.36. For iOS devices, use this: Mozilla/5.0 (iPhone; CPU iPhone OS 15_7_8 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.6 Mobile/15E148 Safari/604.1 You can search by date. Prior to the release on 8/26, users have log entries like this: GET /case-documents/16752-22/face5d2e-04b9-4d11-b28c-620014706fb7/document-download-url. After 8/26 there are no document downloads from mobile devices.
Cause of Bug, If KnownarrayIndex, a required property for rendering the document detail modal in mobile was not provided to that component.
Definition of Ready for Bugs(Created 10-4-21)
Definition used: A failure or flaw in the system which produces an incorrect or undesired result that deviates from the expected result or behavior. (Note: Expected results are use cases that have been documented in past user stories as acceptance criteria and test cases, and do not include strange behavior unrelated to use cases.)
The following criteria must be met in order for the development team to begin work on the bug.
The bug must:
Be focused on solving a user problem
Contain data for all fields in the bug template, so the team can pick it up and begin working immediately
Process: If the unexpected results are new use cases that have been identified, but not yet built, new acceptance criteria and test cases should be captured in a new user story and prioritized by the product owner.
If the Court is not able to reproduce the bug, add the “Unable to reproduce” tag. This will provide visibility into the type of support that may be needed by the Court. In the event that the Court cannot reproduce the bug, the Court will work with Flexion to communicate what type of troubleshooting help may be needed.
Definition of Done (Updated 4-14-21)
Product Owner
[ ] Bug fix has been validated in the Court's test environment
Engineering
[x] Automated test scripts have been written
[x] Field level and page level validation errors (front-end and server-side) integrated and functioning
[x] Verify that language for docket record for internal users and external users is identical
Describe the Bug When an external user accesses the docket record of one of their cases from their mobile device:
Business Impact/Reason for Severity high
In which environment did you see this bug? Prod, Test
Who were you logged in as? Petitioner, Practitioners
What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.) This bug was reported to us via a DAWSON Support ticket from a Petitioner attempting to view a document on their case.
To Reproduce Steps to reproduce the behavior:
Expected Behavior Logged in users should be able to click on a document link and view documents when using a mobile device, also, formatting of the document link needs to be consistent for all users when viewing the docket record on a mobile device.
Actual Behavior Logged in public users experience a white screen if they click on a document link on a mobile device, and they cannot get out of it, they have to restart their session and log back in to DAWSON. Also, the formatting of the document title is different for public logged in users.
Notes In looking at the Kibana logs, it would appear that this started happening after the 8/28 release. It may have something to do with the refactoring that was done in story #10106 with the mobile view of the docket record? Prior to the release, we see log entries of document downloads from users accessing DAWSON on mobile devices. If you would like to check this out in the logs as well, add a filter for
request.headers.user-agent
and then for Android devices add this:Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Mobile Safari/537.36
. For iOS devices, use this:Mozilla/5.0 (iPhone; CPU iPhone OS 15_7_8 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.6 Mobile/15E148 Safari/604.1
You can search by date. Prior to the release on 8/26, users have log entries like this:GET /case-documents/16752-22/face5d2e-04b9-4d11-b28c-620014706fb7/document-download-url
. After 8/26 there are no document downloads from mobile devices.Cause of Bug, If Known
arrayIndex
, a required property for rendering the document detail modal in mobile was not provided to that component.Definition of Ready for Bugs(Created 10-4-21)
Definition used: A failure or flaw in the system which produces an incorrect or undesired result that deviates from the expected result or behavior. (Note: Expected results are use cases that have been documented in past user stories as acceptance criteria and test cases, and do not include strange behavior unrelated to use cases.)
The following criteria must be met in order for the development team to begin work on the bug.
The bug must:
Process: If the unexpected results are new use cases that have been identified, but not yet built, new acceptance criteria and test cases should be captured in a new user story and prioritized by the product owner.
If the Court is not able to reproduce the bug, add the “Unable to reproduce” tag. This will provide visibility into the type of support that may be needed by the Court. In the event that the Court cannot reproduce the bug, the Court will work with Flexion to communicate what type of troubleshooting help may be needed.
Definition of Done (Updated 4-14-21)
Product Owner
Engineering
test
environment if prod-like data is required. Otherwise, deployed to anyexperimental
environment for review.