BUG: Trial Session Batch Download Cases Pre-Check UI

[matthopson]

Describe the Bug In order to address issues with the downloader hanging up with no indication what happened, a step was added before downloading cases to verify the existence of files to be zipped up. On cases that are very large, this causes a delay after clicking the Download button before you see the progress indicator, so it appears nothing is happening.

Business Impact/Reason for Severity May cause user to assume it's not working and keep trying without immediate response.

In which environment did you see this bug? mig

Who were you logged in as? Judge Urda

What were you doing when you discovered this bug? (Using the application, demoing, smoke tests, testing other functionality, etc.) manual testing

To Reproduce Steps to reproduce the behavior:

1. Log in as Judge Urda
2. Go to Trial Session New York City, New York (04/26/21)
3. Ensure case with docket number 27002-17 is present (it has a lot of docket entries)
4. Click Download All Cases
5. Note it appears to do nothing, but after a while the progress indicator will appear.

Expected Behavior Some indication that the system is processing the request should be displayed.

Actual Behavior No indication that anything has happened is present.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• macOS Big Sur
• MS Edge

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Cause of Bug, If Known There is a process that now runs to pre-verify all documents are present before attempting to zip them - which could cause an error. We could consider removing this process and just let them fail when they fail during zipping instead of doing this check, or add some UI that indicates the system is verifying the download.

Process for Logging a Bug:

• Complete the above information
• Add a severity tag (Critical, High Severity, Medium Severity or Low Severity). See below for priority definition.

Severity Definition:

• Critical Defect Blocks entire system's or module’s functionality No workarounds available Testing cannot proceed further without bug being fixed.

• High-severity Defect Affects key functionality of an application There's a workaround, but not obvious or easy App behaves in a way that is strongly different from the one stated in the requirements

• Medium-severity Defect A minor function does not behave in a way stated in the requirements. Workaround is available and easy

• Low-severity Defect Mostly related to an application’s UI Doesn't need a workaround, because it doesn't impact functionality

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
• [x] New screens have been added to pa11y scripts
• [x] All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html
• [x] READMEs, other appropriate docs, JSDocs and swagger/APIs fully updated
• [x] UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required)
• [x] Interactors should validate entities before calling persistence methods
• [x] Code refactored for clarity and to remove any known technical debt
• [ ] Deployed to the Court's test environment

[matthopson]

Notes from PR (https://github.com/ustaxcourt/ef-cms/pull/1104)

We've discovered that when testing this on very large trial sessions with cases with lots of docket entries, this process is a bit slow. One option was to add some kind of indicator that this is being done, but after chatting with @klohman about it, it seemed like doing this step on every download was impacting users far more than the few that will fail.

There was already better error handling / logging in a previous issue related to downloads, the intent of these code changes on top of that was for diagnosing when cases fail due to unreachable documents - something that did happen, but should not happen that often.

To both provide a better user experience and preserve the diagnostic value in checking the files first that logging was left in place in this PR, but wrapped in a conditional that can be passed via a REST client on an offending trial session to generate better logs in the system.

[JessicaMarine]

@mmarcotte to test by removing PDF from a case on a session and seeing if it throws the proper error when downloading all cases

[mmarcotte]

Just need the log moved to the applicationContext.logger.error(...) on the onError call.

[matthopson]

@mmarcotte I updated the branch yesterday, but failed to create a new PR. https://github.com/ustaxcourt/ef-cms/pull/1146