Closed cholly75 closed 1 month ago
Pre-refinement questions:
Judges are part of their own chamber section.
Expected Results:
Part 1
Expected Results:
Part 2
Expected Results
Part 3
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Expected Results:
Functionality in the UI looks good, I believe the remaining items in the test cases probably need to be checked by Court Engineering. @jimlerza @jtdevos @Mwindo
Specifically, please check the documentation to ensure that it is understandable and ensuring that when an admin runs the deactivate court user script, the judge user (or any other user they are deactivating) is disabled (deleted?) in Cognito. @Mwindo said that this step wasn't happening when we were testing. Thanks!
Testing Feedback: @Mwindo
If a clerk adds a new trial session and adds the judge or edits the assigned judge on an upcoming trial session to a different judge, the chambers phone number of the selected judge no longer auto-populates when a judge is selected.
This is currently still working on Staging.
Update: The above was caused because there was an intervening glue job that cleared out the phone numbers added to Dynamo in test. After re-running the script to add these phone numbers to test, the issue should now be fixed.
As a court, so that judge personnel changes can be done administratively at the time of need, I need to be able to add, remove, or modify judges and their chambers without needing a code release.
Currently the architecture in DAWSON requires a code release to onboard a new judge, remove a retired/deceased judge, or change a judge from one type to another (e.g., STJ->Regular, Regular->Senior) .
As judges are key personnel here at the Court, we should be able to react quickly to changes needed at that level and ensure DAWSON is up-to-date with the judge roster. We would like to be able to make these changes without requiring a code release, ideally administratively by a Court DevOps user on the back end or in DAWSON itself.
Pre-Conditions
Acceptance Criteria
Notes
Tasks
Test Cases
Story Definition of Ready (updated on 12/23/22)
The following criteria must be met in order for the user story to be picked up by the Flexion development team. The user story must:
Process: Flexion developers and designers will test if the story meets acceptance criteria and test cases in Flexion dev and staging environments (“standard testing”). If additional acceptance criteria or testing scenarios are discovered while the story is in progress, a new story should be created, added to the backlog and prioritized by the product owner.
Definition of Done (Updated 5-19-22)
Product Owner
UX
Engineering
efcms-local.json
, 3 local s3 files corresponding to that docketEntryId have been added toweb-api/storage/fixtures/s3/noop-documents-local-us-east-1
test
environment if prod-like data is required. Otherwise deployed to anyexperimental
environment.staging
environment.