Closed mariahkannenberg closed 2 years ago
On the Add Docket Entry page of a lead case in a group, when a user clicks "Save and Serve", display a modal with modified content:
After the user clicks "Yes, Serve", keep the existing flow and navigate to the Docket Record page:
Expected Results
Expected Results
Expected Results:
Expected Results:
Expected Results
Expected Results
Expected Results
Expected Results
Expected Results:
Expected Results:
Expected Results
Expected Results
Expected Results
Expected Results
Expected Results:
Expected Results:
Expected Results
Expected Results
Expected Results:
Expected Results
Expected Results:
Expected Results:
Expected Results
Expected Results
Expected Results:
Expected Results:
Expected Results
Expected Results
Created the consolidated-case-with-duplicating-docket-entries
feature flag.
The model is located at web-client/src/views/ConfirmInitiateServiceModal.jsx
.
web-client/src/presenter/sequences/serveCourtIssuedDocumentFromDocketEntrySequence.js
is the sequence that most likely runs when someone clicks "Yes, Serve". That sequence could be overridden though.
It was discussed that if a Decision type of document is added as a docket entry in the lead case, then the updated modal that displays for the user to select additional cases to file in will NOT appear. Decision documents are only to be filed in individual cases. I added test case 9 for this scenario.
Need to add setupConsolidatedCasesAction
to web-client/src/presenter/sequences/openConfirmServeCourtIssuedDocumentSequence.js
for when we tackle serving (without filing) of court issued documents.
Need to update web-client/src/presenter/actions/serveCourtIssuedDocumentAction.js
and shared/src/business/useCases/courtIssuedDocument/serveCourtIssuedDocumentInteractor.js
too.
I deleted the original test case 4 that involved saving the docket entry rather than save and serve since we split that workflow out of this story. The test cases that were in here are now in story 9513.
TODO
Issue found during UX Review: Our mockups incorrectly indicated modal text should say "The following document will be served on all parties:". This text should be corrected to say "The following document will be served on all parties in selected cases"
Found an issue while testing. When serving a document, if the petitioner has paper service, the print for paper service screen overtakes all DAWSON tabs that you have open. This is very confusing if a user needs to issue an Order in a Consolidated group of cases. If this user is doing multiple things in DAWSON, they may accidentally print the same paper service multiple times. They may not realize that it is the same document. Based on the conversation we had during standup, it seems to be related to the current websocket configurations? Here are the steps to take to recreate the issue:
1 - Have multiple tabs open with various cases (can have cases that are in a Consolidated group, or just random cases)
2 - Go to the lead case (22447-16) and create an order (or you can also create an order in docket 22449-16- a member case)
3 - On the pop-up modal for selecting which cases to serve the document on, be sure to select a case that has petitioners that receive paper service (in my testing, docket 22449-16 has Paper service)
4 - The Print for paper service screen appears.
5 - This screen will appear on ALL DAWSON tabs that you have open.
Found an issue while testing today. I am unable to serve a document to a Consolidated group. I receive a spinner of doom. Here are the steps to recreate it.
Note: Chris Holly also experienced this same behavior.
Here is a screen capture:
On TEST, when you are serving a court issued document via pdf upload in a member case, or just a regular ol' case that isn't part of a CG, you get the pop-up modal that has the updated wording for Consolidated cases...Granted, it doesn't have the checkboxes, but the wording has changed from what it was originally, which could cause some confusion.
Here is what it is currently displaying when serving a document on a non lead case on TEST:
Here is the language that currently exists when serving (without the Consolidated functionality deployed) on Staging:
Approved to remove feature flag
As a docket clerk, in order to prevent having to add multiple docket entries in a group of consolidated cases, I need the system to automatically add a docket entry to any other cases in the group that I choose when adding a docket entry for a Draft in the Lead case.
When a document is filed in a case that is part of a consolidated group (CG), it is often necessary to have that document reflected on the docket record for some or all of the other cases part of that group. Currently, this requires the court user to manually scan/upload the document(s), send a message, and then add the docket entry individually for each case in the group as needed, which can take a lot of time and introduces opportunity for error.
We would like the Court to have the ability when adding a docket entry in the Lead case of the CG (designated currently as the lowest-numbered case in the CG) to select which, if any, other cases in the CG to automatically create a docket entry. This initial story will focus on court-issued documents only.
Pre-Conditions
Acceptance Criteria
Security Considerations
Notes
Questions from UX
Engineering
How do we want to handle duplicate docket entries?
Tasks
Test Cases
Definition of Done (Updated 8-28-19)
Product Owner
UX
Engineering