bcgov / bcgov/SIMS

Mass manual reassessment part 1 (Reassess function)

Open
#6,530 0 comments 0 reactions 1 assignee Claimed by @Joshua-Lakusta View on GitHub
Backend Business Enhancement User Story
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

image.png

### 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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.