Closed emilyjablonski closed 1 week ago
Name | Link |
---|---|
Latest commit | 76e29cc2c20134a649ab735ae446a7777d822378 |
Latest deploy log | https://app.netlify.com/sites/partners-bloom-dev/deploys/66e2ff6592c5ce00086995de |
Deploy Preview | https://deploy-preview-4279--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 | 76e29cc2c20134a649ab735ae446a7777d822378 |
Latest deploy log | https://app.netlify.com/sites/bloom-exygy-dev/deploys/66e2ff6593ba010008b0137b |
Deploy Preview | https://deploy-preview-4279--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.
Related to merge of: https://github.com/bloom-housing/bloom/pull/4275
This PR addresses #4224
Description
Adds in the total number of applicants and number of applicants per preference into the public site lottery results page.
I created a new table that stores the totals in a very similar way to how we store lottery positions. I had performance concerns over querying the lottery positions table every time a user needs to see their results page as it will have 1000s of rows after just one lottery is run.
There's also some misc. test coverage.
How Can This Be Tested/Reviewed?
Submit an application to a listing and claim a preference. Run and release the lottery. Ensure that the total number of applications and number of applications that claimed that preference are correct.
Handling listings without preferences or a user who doesn't claim any is a separate ticket.
Author Checklist:
yarn generate:client
and/or created a migration when requiredReview Process: