Closed TiCampbell closed 1 year ago
When updating the application_ami
table via the IQ Navigator portal, we'll need a verification to ensure there's exactly one AMI value marked active==True
for each householdNum
value. There isn't a way to catch when a necessary 'active' value DNE in the app without causing a lot of overhead, so it needs to be done on table update.
This will also need an email reminder to update the values (this hasn't been created as an Issue yet). This will be a reminder to use the HUD values (exact methodology is being worked out by Merry and Tim) to calculate and upload AMI values for the differing individuals in household. Current-year values are released sometime in April and must be in use within 45 days of June 2 - initial reminder in May, then a second reminder on June 2 if current-year values don't exist in the application_ami table (e.g. they haven't yet been uploaded).
This was moved to Get-Your/Get-Your#46 because it needs to be implemented likely before this portal is complete.
This is no longer necessary now that the platform no longer allows tax forms. Since we're relying on external programs for the income verification, we only have to verify the applicant is in their selected Eligibility Programs, which have already-designated AMI percentages. We no longer have to deal with the conversion of AMI percentage to dollar amount.
The IQ Navigator will need to update the AMI levels each year (based on the Census Bureau's annually-updated data). Publishing the new AMI values should also kick off (or prompt to kick off) and automated email to users to update their information to see if they qualify for additional programs.
While we have active/inactive Booleans for the AMI levels, they're not currently operational because the table's primary key is incorrectly defined (to be fixed in a different task).
The update mechanism will also affect the string
grossAnnualHouseholdIncome
value (e.g. '0.3000^0.5000') and the associated numericAMIRange_min
andAMIRange_max
values. We originally went with hardcoding the string value because at the time there was no way to ensure that the AMI values the eligibility was based on weren't going to be updated with no history of the previous value. Now that they're going to be updated in an online portal, I can have the backend mark the previous value asinactive
instead of deleting and then create a relationship between that value and the AMI percentages (based on indices to theapplication_ami
table, which means we can remove thegrossAnnualHouseholdIncome
string altogether). This will require a rearchitecture of the eligibility as well.This should also have a checkbox to update the dev database with the new values (default selected?). The same checkbox should be includes with the other global settings (e.g. program eligibility definitions).