[Sync Enhancement | Data Access Checker] Data filtering based on the Related Entity Location

[dubdabasoduba]

Keyword Definition

• Related Entity - What the data collected for (e.g. Family/Household, Family/Household member, Patient, Service Point or Product).
• Related Entity Location - This term is used to refer to location(s) associated with the client.
  • This would mean the location where the family or family member lives for the case of the SID (Summit Institute for Development) applications
  • This would mean the service point of where data collected belongs to for the case of EUSM (End User Supply Monitoring)
• Sync Locations - These are the locations used to filter the data to be synced to the application.

Context

• Sync by Related Entity Location means getting all the resources that have a Related Entity Location ID that is a child or equal to the user sync locations.
• The generation of the tags to filter by would work almost similar to the Sync by Practitioner Location https://github.com/opensrp/fhircore/issues/1662
• This sync strategy will work as follows.
  • The Gateway will check the Application Config to figure out the sync strategy used. Filtering by Related Entity Location (REL) will only be triggered for the sync strategy is REL
  • The gateway then needs to figure out which option of REL it needs to use. This will be done by checking the Keycloak ROLEs on the user's auth token.
  • If the user has the ROLE_VALIDATE_ASSIGNMENT the gateway will do the following.
    • Ignore the request param syncLocation, it will instead fetch the user-assigned location and its children. It will then use this list of location IDs to filter data.
  • If the user does not have the ROLE_VALIDATE_ASSIGNMENT the gateway will do the following.
    • Take the request param syncLocation, it will fetch the location IDs in the params, fetch their children and use the resulting list to filter the data
  • The tags created by this strategy should target the REL tag created here https://github.com/opensrp/fhircore/issues/3077

Technical Description of enhancement

• [ ] From the request parameters get the Sync locations from the syncLocation param.
• [ ] For each Sync Location fetch its hierarchy and fetch the Location IDs of all its children.
  • [ ] Add the Children Location IDs + the Sync Location IDs to an array
• [ ] Use the array created above to create query parameters for the FHIR Store e.g. HAPI then use these queries to fetch and filter data from HAPI
  • https://<base_url>/fhir/Patient?_tag=https://smartregister.org/related-entity-location-tag-id|137151 -- Location 1
  • https://<base_url>/fhir/Patient?_tag=https://smartregister.org/related-entity-location-tag-id|136256--Location 2
• [ ] Remember to add the other pagination request params to each request.
• [ ] Bundle the responses from each of the queries into one response and send that back.
  • [ ] This Bundle should match the FHIR resource Bundle specifications.

Acceptance Criteria

• [ ] This functionality should only kick in if the sync strategy Related Entity Location is used
• [ ] Return only the resources that have a Related Entity Location ID meta.tag that is a child or equal to the user sync locations.

Depends On https://github.com/opensrp/fhircore/issues/3053

More information on why we need to make this change

• https://docs.google.com/document/d/1D7fXYo3zFMAO3j5Vh8FmpfSVeRfxfVjHAefDtw2KmSk/edit?usp=sharing

[pld]

I don't think the client should be responsible for constructing the location list, I think the gateway should, that way we reduce the round trips and we have that business logic on the server side, so we can better control it. I.e. the flow is

• Fetch sync locations from the syncLocations param
• Send sync request to a new gateway endpoint with
  • syncLocations array
  • metaTag to sync on (e.g. practioner-location-at-write-time entity-location-at-write-time)
  • pagination

The logic in the gateway endpoint converts the locations array into a set of locations

[dubdabasoduba]

I don't think the client should be responsible for constructing the location list, I think the gateway should, that way we reduce the round trips and we have that business logic on the server side, so we can better control it. I.e. the flow is

• Fetch sync locations from the syncLocations param

• Send sync request to a new gateway endpoint with

  • syncLocations array
  • metaTag to sync on (e.g. practioner-location-at-write-time entity-location-at-write-time)
  • pagination

The logic in the gateway endpoint converts the locations array into a set of locations

@pld that's the idea

The client will only be responsible for sending the syncLocations param. The syncLocation are the locations selected by the user on the app, for microplanning apps or the logged in user assigned location for health workflow apps

The gateway will then be responsible for fetching the other child locations internally

[pld]

OK, that's not clear to me from the technical description in this issue, this reads like the client is doing that, can we move that part of this issue out to an issue in the info gateway repo

[ndegwamartin]

Looks good, a few thoughts

• The entry in the json app configs for the new sync strategy should be the pascal cased literal 'RelatedEntityLocation' to match the others.
• On the role we can invert the concept so that it reflect exactly the grants e.g. ROLE_ALL_LOCATIONS or ROLE_ALL_LOCATION_DATA, ROLE_REL_ALL_LOCATIONS or ROLE_RELATED_ENTITY_LOCATIONS_ALL
• When constructing the location ids data structure when processing the hierarchy we should use a SET to avoid duplicates

[pld]

Cool I like the exact grant idea, it's unclear what the options are, it seems like they're just

• ROLE_ALL_LOCATIONS
• ROLE_ASSIGNED_LOCATIONS

b/c we're not saying anything specific about the sync strategy in the grant, only whether the user has access to all or only their assigned locations and sub-nodes.

[dubdabasoduba]

@pld @ndegwamartin we can use ROLE_ASSIGNED_LOCATIONS

[ndegwamartin]

@pld @dubdabasoduba yeah since the two will be mutually exclusive, we should only pick one of the roles .

For the two options above, I'd go with ROLE_ALL_LOCATIONS because IMO it authorises ability to view all locations (in line with my understanding of roles) rather than ROLE_ASSIGNED_LOCATIONS which acts more as a flag

[pld]

I'm good with that, makes sense