Feature - Permit Bulk Export on Compartment by FHIR Query

[jdar8]

What was done:

• Add new AuthResourceResolver
• Add 2 new rules to support these permissions. They need to match resources/compartments based on a FHIR query (see cases in issue comments)
  • These rules use a new AuthResourceResolver service to query the DB to apply SearchParameter matching using an InMemoryResourceMatcher
• Add new logic to rule builder, to allow building these new rules
• Tests and changelog

Closes #7342

[robogary]

Formatting check succeeded!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (rel_8_6@ce8d22d). Learn more about missing BASE report.

Additional details and impacted files

@@            Coverage Diff             @@
##             rel_8_6    #7310   +/-   ##
==========================================
  Coverage           ?   83.78%           
  Complexity         ?    30207           
==========================================
  Files              ?     1836           
  Lines              ?   116708           
  Branches           ?    14811           
==========================================
  Hits               ?    97786           
  Misses             ?    12617           
  Partials           ?     6305           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jamesagnew]

I don't love the names of these new methods - All of the existing methods in this interface are verbs (update(), patch(), bulkExport(), etc) that read fluently, but these new ones break that pattern with a really cryptic noun instead.

Do we need these new interfaces and methods at all? E.g. could we move the new functionality into IAuthRuleBuilderRuleBulkExport so that instead of needing to add rule:

builder.allow().bulkExportGroupCompartmentMatcher().groupExportOnGroup("?" + theCompartmentMatcherFilter).withResourceTypes(resourceTypes);

could we just allow a syntax like:

```java
builder.allow().bulkExport().groupExportOnFilter("?" + theCompartmentMatcherFilter).withResourceTypes(resourceTypes);

This would make the API a lot cleaner, and make the new features more discoverable since we wouldn't have 3 top level methods about the same operation.

[jdar8]

That’s a good point. I’ve consolidated the API into IAuthRuleBuilderRuleBulkExport as suggested. Also decided to just go ahead with @TipzCM's suggestion to refactor the Group/Patient rules to have a BaseRuleBulkExportByCompartmentMatcher with shared functionality for the resource types list since it also made the API cleaner in RuleBuilder.

[jamesagnew]

This makes me nervous. I get the design, but it's breaking the well-established pattern we have that auth interceptor doesn't resolve anything, it just looks at the data it's passed and makes a decision.

Instead of creating a loading infrastructure, could we add a new parameter object to STORAGE_PRE_INITIATE_BULK_EXPORT so that BulkExportJobService could handle loading the Group and pass it to AuthInterceptor as a part of the interceptor request? That way AuthInterceptor could look at it and make its decisions without needing to know how to fetch anything

[jdar8]

As discussed during design, we will stick with this approach since there may be some other use cases for this, such as new features for permissioning with $meta and patch. Also, as discussed, added a query count test (BulkDataExportAuthorizationQueryCountTest) to ensure there are 2 select queries during authorization.

[jamesagnew]

I'm not sure I follow why these counts are needed. The logic appears to be:

• If atLeastOneTesterMatches returns false for any patients, immediately DENY
• If atLeastOneTesterMatches returns false for all patients, ALLOW
• If thePatientResources is empty, return no verdict

You should be able to implement that without needing to count anything, and it'll be a whole lot more readable

[jdar8]

Refactored to use booleans instead of counting. Also added some javadoc for the cases.

• null/abstain: If the list of patient resources is empty
• null/abstain: If all Patients evaluate to NO match
• DENY: If some Patients evaluate to match, while other Patients evaluate to NO match
• ALLOW: If all Patients evaluate to match

[jamesagnew]

Thought: Do any user-supplied strings get passed through this? Could it become an attack vector if someone requested a URL with 2 ? in it? (which would technically be illegal HTTP but is something someone could do)

E.g., what if I requested a bulk export with a typeFilter like patient=Patient/BAD,?patient=Patient/GOOD when I'm only approved to see patient/GOOD, could I trick the interceptor?

[jdar8]

Hmm. It is used when parsing typeFilter, which is user supplied.

I've switched over to using Urlutil and MatchUrlUtil to address this and reduce duplication.