Add frontend support for Manage Users pagination

[mpbrown]

FRONTEND PULL REQUEST

Related Issue

• Resolves Add pagination to "Manage users" page for user list #8103

Changes Proposed

• Adds pagination to the Manage Users side nav
• Updates the routing for the default Settings page to use settings/users/:pageNumber so that the page number can be retrieved from the url params
• Adds a "No results found" message with a button to clear the search filter

Testing

• Deployed on dev5
• Select Access organization account from the support admin dashboard
• Select Big Organization, type in "test" for justification, and click Access data
• Select either facility
• Go to the Settings page and it should bring you to Manage Users
• Test that pagination works as expected

Screenshots

Page 1 of results

Page 5 of results

Last page of results

Search results with multiple pages

Search results with single result page

No results found

[mpbrown]

Had to handle this edge case because I encountered an error when I was on page 7 of all results and entered a search query. The app requested page 7 of the search results and the backend calculated the start index as a higher index than the end index. This caused an illegal argument error when attempting to create the sublist

[mpbrown]

One thing I noticed while testing was searching for a user on a previous page, when you have navigated to a later page. The pagination doesn't reset. Hope this video makes more sense of what I'm trying to say 😅

Hmm I'll check with product and design to see what the intended behavior should be in this scenario. Right now the component determines the current page based on the url parameter so in that example the url param would still be 7 even when the search results returned just one page. We could possibly have the frontend trigger a redirect to the 1st page whenever a search is entered. I remember we discovered that focus redirect bug on the results page when we were pairing on this

[khayeni-SL]

In a (probably unlikely) scenario where the results return too many patient names to fit on one page, how would the user navigate to "page 2"? (Ex: There are 20+ Wallaces.) Is there a large lift to have the pagination reflect the results filter?

Alternatively, I'd want to know if pagination could be disabled so it does not imply the user can navigate between pages if the filter is active. cc @kenieh for thoughts

[mpbrown]

In a (probably unlikely) scenario where the results return too many patient names to fit on one page, how would the user navigate to "page 2"? (Ex: There are 20+ Wallaces.) Is there a large lift to have the pagination reflect the results filter?

Yes this type of paginated search should already be supported! So if you were to search by a single character like "a" it'll show multiple pages of filtered results

[mpbrown]

@khayeni-SL @kenieh I updated dev5 with the styling changes and fixed the bug @emyl3 found. The search is now handled with the url query parameter name so when a search is input it will always bring them to the first page of those search results. PR should be all ready for review!

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
85.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[emyl3]

Left a couple nits and one thing I noticed based on our search implementation (Sorry I didn't notice this earlier when you introduced the implementation. 😓)

Looks like this search behaves slightly differently than our other ones.

search.functionality.mov

Let me know what you decide to do. Everything else looks good and works as expected for me.

[emyl3]

nit: do we need this id 🤔

[emyl3]

I forgot we could also add something like the following:

<Route index element={<Navigate replace to="users/1"/>}/>

to default it to the users page like before if someone were to navigate to /settings