Closed ludtkemorgan closed 4 months ago
Name | Link |
---|---|
Latest commit | 9e151b885c6c8f6539593ae5bf3dc7b6f7717dda |
Latest deploy log | https://app.netlify.com/sites/partners-bloom-dev/deploys/668570fb4c6db40008d83d3a |
Deploy Preview | https://deploy-preview-4177--partners-bloom-dev.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Name | Link |
---|---|
Latest commit | 9e151b885c6c8f6539593ae5bf3dc7b6f7717dda |
Latest deploy log | https://app.netlify.com/sites/bloom-exygy-dev/deploys/668570fbea211900082e1f56 |
Deploy Preview | https://deploy-preview-4177--bloom-exygy-dev.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Looks good! While we have this front of mind, maybe we want to consider the case where a unit is created using an AMI from another jurisdiction and then the jurisdiction is set/changed. Just some food for though.
That's a good point! There are a decent amount of units in HBA staging that have AMI charts that aren't associated to the correct jurisdiction. I don't know how common in prod it is, but I think it's something we probably should prevent. I'll create a ticket.
This PR addresses #4174
Description
When making the backend call to get AMI charts on the partner site the jurisdiction id was not getting set. This was due to a change in Prisma where the jurisdiction field was changed to "jurisdictions" so the
watch
function was not looking for the correct fieldHow Can This Be Tested/Reviewed?
Note: a new ami chart was added to the stage seeded data tied to the second jurisdiction so I'd recommend a reseed before testing
Author Checklist:
yarn generate:client
and/or created a migration when requiredReview Process: