Add result and condition filters to test results list

[nathancrtr]

Related Issue

• Closes Condition and result filters on results table #6303

Changes Proposed

• Adds condition and result filters for test results list
• To enable filtering on these values, the test results list now queries the GraphQL endpoint for results rather than test events

Additional Information

• This is a follow-up to Refactor results table to accommodate more diseases #6104
  • This work unrolled individual multiplex results for a test event into separate rows on the result table
  • Filtering worked fine for values that do not change between results within a test (patient name, test date, etc)
  • However, since result and condition vary within a single test event, these filters had to be updated for more granular access
• Adds a new resolver and associated GraphQL schema and query definitions
• Adds new service code and Specifications to apply filters from user to database retrieval

Testing

Name filter

Screen.Recording.2023-10-05.at.4.22.04.PM.mov

Date filters

Screen.Recording.2023-10-05.at.4.22.20.PM.mov

Condition filter

Screen.Recording.2023-10-05.at.4.20.59.PM.mov

Result filter

Screen.Recording.2023-10-05.at.4.21.18.PM.mov

Role filter

Screen.Recording.2023-10-05.at.4.21.34.PM.mov

Facility filter

Screen.Recording.2023-10-05.at.4.25.58.PM.mov

Multiple filters applied; clearing filters

Screen.Recording.2023-10-05.at.4.22.38.PM.mov

[zdeveloper]

LGTU, paired on the review with @mpbrown, some minor suggestions and we believe we need a follow up pr to no hard code the diseases on the disease filter list

[zdeveloper]

remove if statement and only use getFacilityResults

[mpbrown]

Is there a clean way to move this null conditional into the service instead of having it in the resolver? This was related to our other comment about combining getOrganizationResults and getFacilityResults, although not sure whether the different auth requirements complicates this then

[nathancrtr]

I think having this conditional in the resolver makes sense for the auth reasons discussed elsewhere.

Fwiw, this pattern (and the associated auth requirements) are lifted one-to-one from the existing TestResultResolver and TestOrderService classes, which these changes largely supplant:

prime-simplereport/backend/src/main/java/gov/cdc/usds/simplereport/api/testresult/TestResultResolver.java

Lines 46 to 65 in 5140abc

	if (facilityId == null) {
	return tos.getOrganizationTestEventsResults(
	patientId,
	Translators.parseTestResult(result),
	Translators.parsePersonRole(role, true),
	startDate,
	endDate,
	pageNumber,
	pageSize);
	}
	return tos.getFacilityTestEventsResults(
	facilityId,
	patientId,
	Translators.parseTestResult(result),
	Translators.parsePersonRole(role, true),
	startDate,
	endDate,
	pageNumber,
	pageSize);
	}

[zdeveloper]

Per story AC, the values here should be loaded from the backend so we dont have to keep adding more values as we add more diseases, doesnt have to block this PR, but it could be added as a followup pr as part of the same ticket

[nathancrtr]

I'm honestly not sure if I'm sold on pulling those values from the backend here to begin with. Adding new diseases to SimpleReport will already involve touchpoints in the frontend code, like our constants.

Also, HIV and RSV have already been added to the database but we're not ready to expose those values to the disease filter, so we'd need to turn around and hardcode those values somewhere instead.

Basically I'm leaning towards there being a logical distinction between diseases that SR "knows about" and diseases that users can submit for, at least at this time.

Whatchy'all think?

[mpbrown]

Hmm that's a good point where the frontend already requires some hardcoded reference for the diseases. At our next pairing session I'm curious to get your thoughts on this as it relates to what I'm working on with adding HIV support since it seems like we'll always need some way to distinguish which AOE questions to show

[mpbrown]

LGTM! Nice work on this!

[DanielSass]

lgtm

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
6 Code Smells

85.1% Coverage
0.0% Duplication

[emyl3]

@nathancrtr I noticed something interesting with this new functionality... if we correct a result is it now expected that we see the previously corrected test in the results page along with the newly submitted result?

To repro:

• submit a test
• correct result -> click something like "Incorrect test result"
• see that it is added to the queue
• submit the corrected result
• go to the results page and see both the previous test and newly corrected test in the results