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

Analysis - Ignore Restrictions #3662

Closed
2 of 3 tasks
ninosamson opened this issue Aug 27, 2024 · 12 comments
Closed
2 of 3 tasks

Analysis - Ignore Restrictions #3662

ninosamson opened this issue Aug 27, 2024 · 12 comments
Assignees

Comments

@ninosamson
Copy link
Collaborator

ninosamson commented Aug 27, 2024

Acceptance criteria

NOTE: There's also #3028 and #3044

@andrewsignori-aot andrewsignori-aot self-assigned this Aug 28, 2024
@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 28, 2024

Analysis Assumptions

  • Restrictions can be ignored only if associated with the student, active, and have an action associated with disbursements.
    • Stop full time BC funding (created automatically during disbursement);
    • Stop part time disbursement;
    • Stop full time disbursement.
  • Restrictions ignored will be associated with the application ID, which means that editing an application will remove all ignored restrictions associated with that application number since a new application record with a new application ID is created.
  • 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.

Bypass behaviors

  • All disbursements: any disbursement associated with the application will have this restriction ignored if the ignored restriction is active. Any reassessment will continue to ignore the restrictions.
  • Next disbursement only: when the first e-Cert is marked as Ready to send the "ignore restriction" will be updated
    • is_active will be set to false.
    • bypass_removed_by will be set to system user.
    • bypass_removed_date will be set to the current date.
    • removal_note_id will be saved with the text: "Automatically removing bypass after the first e-Cert was generated.".

Proposed table structure

Name: sims.application_restriction_bypasses

  • id: auto-generated.
  • application_id: relation to sims.applications.
  • student_restriction_id: relation to sims.student_restrictions.
  • bypass_behavior: Enum Next disbursement only, All disbursements.
  • creation_note_id: relation to sims.student_notes.
  • bypass_created_by: user that created the bypass.
  • bypass_created_date: date and time the bypass was created.
  • removal_note_id: relation to sims.student_notes.
  • bypass_removed_by: user that removed the bypass.
  • bypass_removed_date: date and time the bypass was removed.
  • is_active: indicates if the bypass should be considered active.
  • [audit fields]

e-Cert Steps Changes

  • ValidateDisbursementPartTimeStep and ValidateDisbursementFullTimeStep should check all Stop disbursement restrictions (currently checking if at least one is present) and ignore the bypassed ones.
  • Create a new step to be executed last (after disbursement is marked as Ready to sent) to remove a bypass if the role is defined as Next disbursement only.

As @Joshua-Lakusta recommendation, the mentioned tickets #3028 and #3044 are no longer needed because #1862 and #1815 will satisfy the requirements.

@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 28, 2024

@Joshua-Lakusta a bypassed restriction should also be part of the logic that prevents the student from accepting an assessment?
If a restriction currently preventing the student from accepting the assessment is bypassed, should the student be able to accept the assessment?
My advice would be "allow the student to accept the assessment".

@andrewsignori-aot
Copy link
Collaborator

@Joshua-Lakusta a bypassed restriction still be listed in the application tracker cards?
For instance, if the student has only one restriction blocking the disbursement and this restriction is ignored, should we still display the below message:
"You have a restriction on your account making you ineligible to receive funding. Please contact StudentAid BC if you still require assistance in identifying the cause of this issue and help resolving the issue."
My advice would be "do not show the message".

@andrewsignori-aot
Copy link
Collaborator

@Joshua-Lakusta currently we have the below possible actions associated with a restriction.

  • No effect;
  • Stop full time BC funding (created automatically during disbursement);
  • Stop part time apply;
  • Stop full time apply;
  • Stop part time disbursement;
  • Stop full time disbursement.

Should we assume the restrictions bypass will be applied only for Stop part time disbursement or Stop full time disbursement?
Is there any plan for Stop full time BC funding?

@Joshua-Lakusta
Copy link
Collaborator

Joshua-Lakusta commented Aug 28, 2024

@andrewsignori-aot a bypassed restriction should also be part of the logic that prevents the student from accepting an assessment?
If a restriction currently preventing the student from accepting the assessment is bypassed, should the student be able to accept the assessment?
My advice would be "allow the student to accept the assessment".
Yes I agree they should be able to accept assessment

@andrewsignori-aot a bypassed restriction still be listed in the application tracker cards?
For instance, if the student has only one restriction blocking the disbursement and this restriction is ignored, should we still display the below message:
"You have a restriction on your account making you ineligible to receive funding. Please contact StudentAid BC if you still require assistance in identifying the cause of this issue and help resolving the issue."
My advice would be "do not show the message".
I agree we should not show the message.

@andrewsignori-aot currently we have the below possible actions associated with a restriction.

No effect;
Stop full time BC funding (created automatically during disbursement);
Stop part time apply;
Stop full time apply;
Stop part time disbursement;
Stop full time disbursement.
Should we assume the restrictions bypass will be applied only for Stop part time disbursement or Stop full time disbursement?
Is there any plan for Stop full time BC funding?

As this is being handled as a manual ministry intervention we should allow them to bypass all restriction types that interfere with the assessment or disbursement. Stop full time BC funding is actually one that we specifically want this functionality for. If the restriction is bypassed we will need it to reassess. There is going to be further analysis around that one however, so we can postpone the issue of automatic reassessment of this one for the future.. At least allow it to be ignorable and if we need to reassess then we can manually force reassessment with the current manual reassess functionality we have now.

@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 28, 2024

@Joshua-Lakusta thanks for the reply all is clear but Stop full time BC funding.

There are two scanrios for the Stop full time BC funding during the disbursement.

Scenario A

a) The student does not have the Stop full time BC funding associated yet, and
b) The student will reach the maximum, reducing his awards and creating the Stop full time BC funding to stop future BC funding awards.

Scenario B

a) The student already has a Stop full time BC funding associated.
b) BC awards will be disbursed as $0.

Question

When the restriction is bypassed, should we completely ignore the verification of the Stop full time BC funding?
Which means,

  • for Scenario A the restriction will never be created if the bypass is added ahead of time;
  • for Scenario B the BC awards will be disbursed with total amounts.

Josh Answers
Scenario A: This is working as I would expect it to. The resolve restriction should only be useable when the restriction currently exists. My question is how is the amount adjusted in this scenario for the app that is going to hit that max in the middle of the app. Does the restriction do it or is it some other function. How would we bypass it for this first application. The ignore has to be a reactive behavior but also must be able to resolve the app that is being reduced. I hope this made sense but we can connect if it doesn't.

Scenario B: This described behavior is correct.

@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 29, 2024

@Joshua-Lakusta I adjusted the "View Modal" as below trying to follow the existing ones from the restrictions.
It is close to the original layout but has some cleanups.

image.png

Looks good! ~Josh

@Joshua-Lakusta
Copy link
Collaborator

@andrewsignori-aot added my answer into your comment on the two scenarios for Stop Full Time BC Funding.

Look at the edit to the View Modal and it looks good overall.

@andrewsignori-aot
Copy link
Collaborator

@Joshua-Lakusta based on the latest replies follow the questions.

Related to "The resolve restriction should only be useable when the restriction currently exists.".
Question 1: should we allow the Ministry to select only active restrictions in the student account?
Question 2: for the Stop full time BC funding, we should first allow the restriction to be created (and the award to be reduced) to then allow the restriction to be bypassed and the awards disbursed with their total amounts?

@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 29, 2024

@Joshua-Lakusta if a currently active student restriction is bypassed and later this restriction (federal or provincial) is marked as resolved, should we deactivate the bypass, or should we maybe display it in the list if the restriction is no longer active?
My recommendation would be to "display it in the list if the restriction is no longer active", for simplicity.

Josh-
For me if the restriction is resolved it should no longer need to be bypassed as its not there. The history of the by pass should show etc so for me I think it should show that it was bypassed but that it no longer is just in case the restriction is added back on it needs to be clear that it needs to be "re bypassed".

@andrewsignori-aot
Copy link
Collaborator

andrewsignori-aot commented Aug 30, 2024

@Joshua-Lakusta if a currently active student restriction is bypassed and later this restriction (federal or provincial) is marked as resolved, should we deactivate the bypass, or should we maybe display it in the list if the restriction is no longer active? My recommendation would be to "display it in the list if the restriction is no longer active", for simplicity.

Josh- For me if the restriction is resolved it should no longer need to be bypassed as its not there. The history of the by pass should show etc so for me I think it should show that it was bypassed but that it no longer is just in case the restriction is added back on it needs to be clear that it needs to be "re bypassed".

@Joshua-Lakusta the scanrio is the below.
a) The restriction is active in the student account.
b) The active restriction is bypassed and is now on the list of bypassed restrictions.
c) The restriction is resolved in the student account, either manually or because it was a federal automatically resolved.

In the above scenario, the history of bypassed restrictions will still display the no longer active student restriction in the history which can be misleading to the user.

My recommendation would be to include the restriction status in the history to make it clear to the user and maybe have the button to "Remove the bypass" disabled.

@sslaws sslaws closed this as completed Sep 4, 2024
@michesmith
Copy link
Collaborator

Moved this Note from Inside the ticket to comments ": Needs an epic to link all tickets @michesmith. " @ninosamson The epics are 2.2.3 Student View Restrictions and 4.5.6 Ministry Mange Student Restrictions and are now tagged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants