Mass manual reassessment part 1 (Reassess function)
- Dominant language
- TypeScript
- Stars
- 29
- Forks
- 15
- PR merge metrics
- No merged PRs in 30d
Description
As a ministry user we require a path to mass reassess applications when there are large scale issues that effect numerous students.
## Acceptance Criteria
### General UI design
- [ ] Create a new ui to allow ministry users to mass manually reassess applications
- [ ] The access to this function will be the same as reports and will exist as a page that is accessed by clicking a value called Mass manual reassessment (located below invoices and reports and will use a generic icon (no preference on icon just something simple that seems to align))
- [ ] Create a new role for this function in key cloak
- [ ] The new role will be assigned to Business Admin and StudentAid full access
- [ ] Only ministry users can see the Bulk Reassessment function.
- [ ] The user can enter or paste multiple application numbers into a designated input field that will be free text and have a vertical scroll. We will display whatever the out of box size is (20 lines i think?)
- [ ] Application numbers can be entered as
- One application number per line
- comma seperated
- Any other options that are normal for these functions
### Page content
> Ministry (page header)
> Manual Reassessment (Black bold)
>
> Batch manual reassessment (Blue header)
> Enter the application numbers that require manual reassessment.
>
> Free text field with (vertical scroll bar)
> Submit

### Pop up modal
- [ ] When the user clicks submit create a pop up modal that validates they want to submit and asks for a note that will be applied to all applications
- [ ] Content
> Are you sure you want to manually reassess all entered applications?
>
> Note: This will only manually reassess the calculations of these assessments.
>
> Cancel Submit
### Outcome rules
- [ ] This function should follow the rules of the manual reassessment and failing on any of these should flag it in the negative outcome fields
- [ ] Must have a calculated assessment.
- [ ] Target the most recent application version
- [ ] Follow the manual reassessment path in the assessment workflow
- [ ] Do not action the date based archived applications
- [ ] For the scholastic standing archiving it should go out for early completion do we need to block this for them.
- [ ] Do not manually reassess a cancelled application
### Fail outcomes
- [ ] Track the following negative outcomes to report to the user when certain applications are no completed
- [ ] Apply a generic comment for why it failed based on the following blockers
- [ ] The application does not have a valid assessment calculation.
- [ ] The application is date archived and not eligible.
- [ ] The application is cancelled and not eligible.
- [ ] The application had an unexpected error. (for anything other than the 3 above)
### Technical tracking
- [ ] When complete create a batch manual reassess ID number associated with that request that is stored in the back end so we can track the request and output
- [ ] Be able to pull the following data on ad hoc request for the following data (until part 2 is complete with view ui)
Application Number
Result: Success or Failure
Error/Failure Reason
- [ ] Create a table on the bottom of the page that shows history
- [ ] Have a status in the table to show when the batch has completed or is in progress. (Completed = every reassessment has been completed to the end. Everything that was able to be created should be calculated to the end and anything that is failing has failed)
- [ ] Above the table there will be generic content
> Batch manual reassessment history (Blue header)
>
> View the history of batch manual reassessments. Each batch shows the submission details and processing status. View the results for a batch to review which applications were successfully reassessed and which failed, including any applicable error details.
>
> Batch ID | Submitted Date | Submitted By | Applications | Successful | Failed | Status | Action
>
Multiple request handling
- [ ] User should not be able to start a new batch submission until the previous batch has at least been processed and records have been created
- [ ] Upper limit is 50 000 entries
**Additional Context**
- Recent hotfixes have lead to very high volumes of students needing manual reassessment. In a full time environment we require a path to manually reassess large numbers of students.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.