Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically Add Deadline When Docketing Status Report Order #10574

Open
33 tasks
cholly75 opened this issue Dec 18, 2024 · 0 comments
Open
33 tasks

Automatically Add Deadline When Docketing Status Report Order #10574

cholly75 opened this issue Dec 18, 2024 · 0 comments

Comments

@cholly75
Copy link
Collaborator

cholly75 commented Dec 18, 2024

As a docket clerk, so that I do not have to manually enter deadlines for status report orders, I need DAWSON to understand the due date present in a status report order and automatically create one as part of the docket entry addition process.

Status report orders (see #10476 for context) all contain a due date as part of the status report order creation process. Currently docket manually adds an appropriate deadline to the case when a status report order is docketed. We would like to automate the creation of this deadline in the same manner we currently do for other orders (i.e., Order for Filing Fee - see #9644) when adding these documents as a docket entry.
 

Pre-Conditions

Acceptance Criteria

  • When a status report order is served, automatically create a Deadline in DAWSON attached to the case for which the status report order is served.
    • The Deadline:
      • Has a Due Date of the same date entered in the Due Date field on the Status Report Order
      • Has a Description of "Status Report Due"
      • Behaves in all other respects as if manually created by a user and can be interacted with in the usual manner (edit/delete functions for authorized users)

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:

  • Is framed in business/user need, the value has been addressed.
  • Includes acceptance criteria
  • Has been refined
  • Pre conditions have been satisfied.

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

  • Business test scenarios have been refined to meet all acceptance criteria
  • Usability has been validated
  • Wiki has been updated (if applicable)
  • Story has been tested on a mobile device (for external users only)

Engineering

  • Automated test scripts have been written, including visual tests for newly added PDFs.
  • Field level and page level validation errors (front-end and server-side) integrated and functioning.
  • Verify that language for docket record for internal users and external users is identical.
  • New screens have been added to pa11y scripts.
  • All new functionality verified to work with keyboard and macOS voiceover https://www.apple.com/voiceover/info/guide/_1124.html.
  • READMEs, other appropriate docs, and swagger/APIs fully updated.
  • UI should be touch optimized and responsive for external only (functions on supported mobile devices and optimized for screen sizes as required).
  • Interactors should validate entities before calling persistence methods.
  • Code refactored for clarity and to remove any known technical debt.
  • If new docket entries have been added as seed data to efcms-local.json, 3 local s3 files corresponding to that docketEntryId have been added to web-api/storage/fixtures/s3/noop-documents-local-us-east-1
  • Acceptance criteria for the story has been met.
  • If there are special instructions in order to deploy into the next environment, add them as a comment in the story.
  • If the work completed for the story requires a reindex without a migration, or any other special deploy steps, apply these changes to the following flexion branches:
    • experimental1
    • experimental2
    • experimental3
    • experimental4
    • experimental5
    • experimental6
    • develop
  • Reviewed by UX on a deployed environment.
  • Reviewed by PO on a deployed environment. Can be deployed to the Court's test environment if prod-like data is required. Otherwise deployed to any experimental environment.
  • Deployed to the Court's staging environment.
@cholly75 cholly75 moved this to Product Backlog/Bugs in US Tax Court Board Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Product Backlog/Bugs
Development

No branches or pull requests

1 participant