Ignore restrictions for specific disbursement(s) within an assessment

[JasonCTang]

As a Ministry user I want the ability to ignore a restriction for any number of disbursements for the current application So That the next disbursement only will be disbursed OR all outstanding disbursements for that application will still be disbursed.*

When Ministry users select to 'ignore' a restriction, they can choose to ignore it for the application OR for ALL remaining disbursements of that assessment. When a restriction is ignored for a disbursement, it will not be considered when determining if the ECert should be generated for that application. A function to reverse the ignore status and have it be reviewed at ECert generation needs to also be developed.

Note that the ignore action is applied at the disbursement level for the application. So if the application is reassessed, the restriction WILL be automatically ignored for the new assessment. In other words, Ministry users can ignore the restriction for subsequent assessment or reassessments within the single application. If the ministry want to reapply the restriction to the application they will need to have a function to remove the the ignored restriction status. The student would then be expected to call the Ministry and ask for the restriction to be ignored again in this case.

When a Ministry user chooses to ignore a restriction, automatically generate a note at the time it is selected with information on which restriction was ignored for which application and who performed the ignore. (No user input for this note.)

Ministry staff will also need the ability to undo this ignoring of a restriction so that it becomes effective on the assessment again and will block ECert generation.

Linked with UX/UI piece in Ticket #1862

Acceptance Criteria

• [ ] Allow Ministry staff to ignore any restriction (provincial or federal) for:
• The next disbursement sent for the application. Whichever disbursement sent happens after that option is enabled, the eCert check continues to ignore/bypass that restriction. (I.e. any re-assessment will still disable the flag on the first eCert occuring since the restriction was ignored). Once the first eCert goes out after the rule was applied resets/removed the ignore rule.
• OR all disbursements associated with an application. If application gets re-assessed, all disbursements are still ignored.
• [ ] Ministry can apply this 'ignore' rule at any time, and do this for an infinite number of applications associated with the student.

Technical

• [x] Create DB migration for the new table.
  • Name: sims.application_restriction_bypasses
  • id: Auto-generated sequential primary key column.
  • application_id: Reference to the student application that will have the bypass applied.
  • student_restriction_id: Active student restriction to be bypassed.
  • bypass_behavior (Postgres Enum): Defines how the bypass should behave, for instance, until when it will be valid.
  • is_active: Indicates if the bypass should be considered active.
  • creation_note_id: Note when the bypass was created.
  • bypass_created_by: User that created the bypass.
  • bypass_created_date: Date and time the bypass was created.
  • removal_note_id: Note when the bypass was removed.
  • bypass_removed_by: User that removed the bypass.
  • bypass_removed_date: Date and time the bypass was removed.
  • [audit fields]
• [x] Active bypasses should behave accordingly to below behaviors.
  • [x] All disbursements: any disbursement associated with the application will have this restriction ignored if the bypass is active. Any reassessment will continue to ignore the restrictions.
  • [x] Next disbursement only: when the first e-Cert is marked as Ready to send the restriction bypass will be updated
  • is_active will be set to false.
  • bypass_removed_by will be set to the system user.
  • bypass_removed_date will be set to the current date.
  • removal_note_id will be saved with the text: "Automatically removing the bypass from the application number 1234567890 after the first e-Cert was generated.".
  • [x] Create a new step to be executed last for part-time and full-time, suggested name RestrictionBypassesResolutionStep.
• [x] While executing the restrictions validations for part-time/full-time list all the active bypasses considered.
• [x] Once a restriction is bypassed it will also not be returned as a result from the method executePreValidations, which means:
  • be ignored while the student is accepting an assessment;
  • do not be listed in the application tracker information.
• [x] Implement the below processes to ignore restriction actions.
  • [x] Stop part time disbursement should check for all restrictions (currently checking if at least one exists). If at least one is present and not ignored, the disbursement will be blocked. To be applied in the ValidateDisbursementPartTimeStep.
  • [x] Stop full time disbursement should check for all restrictions (currently checking if at least one exists). If at least one is present and not ignored, the disbursement will be blocked. To be applied in the ValidateDisbursementFullTimeStep.
  • [x] Stop full time BC funding once ignored should allow a manually triggered reassessment to have the BC awards full amounts disbursed (in case it was partially paid the regular process will deduct any value already paid, as usual).
  • [x] The step ApplyStopBCFundingRestrictionFullTimeStep must be ignored. Log the message "The application has an active bypass for BCLM. The verification will be ignored.".
  • [x] The step AssertLifeTimeMaximumFullTimeStep must be ignored.
• [x] E2E Tests
  • Should generate BC awards amounts with no restriction deductions when a student has an active 'Stop full time BC funding' restriction and it is bypassed.
  • Assert expected log messages for both ignored steps.
  • Should have the e-Cert generated for a full-time application when a student has an active 'Stop full time disbursement' restriction and it is bypassed.
  • Should have the e-Cert generated for a part-time application when a student has an active 'Stop part time disbursement' restriction and it is bypassed.
  • Should prevent an e-Cert generation when multiple 'Stop full time disbursement' restrictions exist and only one is bypassed.
  • Should prevent an e-Cert generation when multiple 'Stop part time disbursement' restrictions exist and only one is bypassed.

[HRAGANBC]

@Joshua-Lakusta @CarlyCotton

As a business process, do we need any supplementary steps when the application is re-assessed and the restriction is automaticaly re-applied? Like an email trigger to JIRA notifying them?

[ninosamson]

Discuss whether or not this can be ignored at application level rather than assessment.

[Joshua-Lakusta]

@HRAGANBC @CarlyCotton. Please review for any errors in my update. Thank you

[HRAGANBC]

@Joshua-Lakusta revised the logic to make clear what happens when re-assessment occurs. Otherwise good from my end

[andrewsignori-aot]

Demo

Student Portal

• [ ] Login as student andrew_signori_13.
• [ ] Show part-time application 2024000032 with assessment blocked.
• [ ] Active the bypass manually on DB.
• [ ] Accept the assessment.

Institution

• [ ] Log in to institution SIMS_COLLE.
• [ ] Approve the COE.

Student Portal

• [ ] Deactivate the bypass manually on DB.
• [ ] Show the restriction message in the cards.
• [ ] Active the bypass manually on DB.
• [ ] Show the restriction message in the cards.
• [ ] Deactivate the bypass manually on DB.
• [ ] Try to generate the e-Cert
• [ ] Show the queue logs.
• [ ] Active the bypass manually on DB.
• [ ] Show the queue logs.
• [ ] Show student notes.

@CarlyCotton this is what is planned for the demo.