feat: msq search and sort #5711
Conversation
✅ Deploy Preview for bloom-flagly canceled.
|
✅ Deploy Preview for bloom-angelopolis canceled.
|
✅ Deploy Preview for partners-bloom-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
I was only able to test this by switching the endpoint to a POST endpoint instead of a GET. I struggled to test these filters while the endpoint is a GET. The swagger UI does not handle it correctly and trying to use postman or any other tool gives me errors due to incorrect formatting of the filter.
What would be your thoughts on making a new POST list endpoint and then slowly migrate all the current usages of the list endpoint to the POST one? You can still use the same service code, just add a new endpoint @Post('list') and still call this.multiselectQuestionService.list. I'm ok with sticking with a GET though if you prefer to try to use GETs for these use cases
Also I think some small updates to the e2e test would make our test coverage even better! But I was unable to find any functional issues!
| expect(multiselectQuestions).toContain(multiselectQuestionB.text); | ||
| }); | ||
|
|
||
| it('should get multiselect questions from list endpoint when params are sent', async () => { |
There was a problem hiding this comment.
suggestion: The unit tests are good tests for making sure we are creating the right queries with the passed in parameters. However they don't truly test if the correct data is returned from the DB since we are mocking out the DB responses. I like the tests here but we could get some extra verification by updating what this test tests.
Some suggestions:
- create some multiselectQuestions that should not be expected to be returned
- Add more than just a filter on jurisdiction to make sure multiple filters work
- Create a new jurisdiction just for this test so we can verify an exact length instead of
toBeGreaterThanOrEqual. This would work because we are filtering by jurisdiction id and these would be the only MSQs that are tied to that jurisdiction - Add an orderBy to make sure response it returned in the correct
There was a problem hiding this comment.
I'm not going to be able to add all these tests before I sign off. Will add them in the new year
This PR addresses #(5562)
Description
Updates MSQ GET list query params to allow for: pagination, search by name, filtering by (applicationSection, jurisdiction, status), and ordering by (applicationSection, jurisdiction, name, updatedAt).
How Can This Be Tested/Reviewed?
Start application
Using api, test each of the new query param options. You will need to hit it using curl or a API tool such as Postman.
Examples:
curl -X 'GET' \ 'http://localhost:3100/multiselectQuestions?page=1&limit=10' \ -H 'accept: application/json'curl -X 'GET' \ 'http://localhost:3100/multiselectQuestions?filter%5B0%5D%5B%24comparison%5D=IN&filter%5B0%5D%5Bstatus%5D=active,visible' \ -H 'accept: application/json'Author Checklist:
yarn generate:clientand/or created a migration when requiredReview Process: