Fix: [AEA-6446] - Bug fix single patient return not loading prescription findings#1975
Fix: [AEA-6446] - Bug fix single patient return not loading prescription findings#1975connoravo-nhs wants to merge 4 commits intomainfrom
Conversation
Signed-off-by: Connor Avery <214469360+connoravo-nhs@users.noreply.github.com>
Signed-off-by: Connor Avery <214469360+connoravo-nhs@users.noreply.github.com>
|
This PR is linked to a ticket in an NHS Digital JIRA Project. Here's a handy link to the ticket: AEA-6327 |
There was a problem hiding this comment.
Pull request overview
Fixes a navigation bug in the CPT UI where a single patient result from a basic-details search could lead to an incorrect redirect (preventing prescription findings from loading) by ensuring the subsequent prescription list lookup uses the correct searchType.
Changes:
- Ensure
searchTypeis set to"nhs"when basic-details search returns exactly one patient and the flow pivots to an NHS-number-based prescription lookup. - Add additional logging when
NavigationProvider.getRelevantSearchParameterscan’t return parameters for the requested search type. - Update the unit test expectation for the single-result basic-details search flow.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
packages/cpt-ui/src/pages/PrescriptionListPage.tsx |
Minor condition formatting for the basic-details redirect guard. |
packages/cpt-ui/src/pages/BasicDetailsSearchResultsPage.tsx |
Sets searchType: "nhs" when exactly one patient is returned. |
packages/cpt-ui/src/context/NavigationProvider.tsx |
Adds an info log when relevant search parameters aren’t available. |
packages/cpt-ui/__tests__/BasicDetailsSearchResultsPage.test.tsx |
Updates expectation to include searchType: "nhs" for the single-result flow. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (payload.length === 1) { | ||
| const relevantParams = | ||
| navigationContext.getRelevantSearchParameters("basicDetails") | ||
| // Set the search type before attempting search again | ||
| // As we'll now be using the nhs number search | ||
| searchContext.setAllSearchParameters({ | ||
| ...relevantParams, | ||
| nhsNumber: payload[0].nhsNumber | ||
| nhsNumber: payload[0].nhsNumber, | ||
| searchType: "nhs" | ||
| }) |
There was a problem hiding this comment.
setAllSearchParameters overwrites searchType; this block correctly sets searchType: "nhs" for the single-result path, but the row-click path in the same page still calls setAllSearchParameters without searchType, which will clear it and can cause PrescriptionListPage to hit the default case and redirect to prescription-ID search. Consider also setting the appropriate searchType (and updating the related row-click/link/key navigation tests accordingly) so navigation is consistent for both single and multi-result flows.
| logger.info("Navigation: No relevant search parameters found", { | ||
| searchType, | ||
| originalSearchParameters | ||
| }) |
There was a problem hiding this comment.
This log line includes originalSearchParameters, which can contain patient identifiers (e.g. NHS number, name, postcode). Logging these at info level risks leaking PII into browser logs and creates noisy telemetry since getRelevantSearchParameters is called frequently. Consider removing the parameters from the log (or redacting sensitive fields) and/or downgrading to debug/trace.
Signed-off-by: Connor Avery <214469360+connoravo-nhs@users.noreply.github.com>
connoravo-nhs
changed the title
|
Summary
Details
Fix the bug where a single patient returned on basic details search was being incorrectly redirected to search by prescription ID page, because it didn't have the searchType handled correctly.