Closed dubdabasoduba closed 5 months ago
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
syncLocations
paramThe logic in the gateway endpoint converts the locations array into a set of locations
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
paramSend 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
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
Looks good, a few thoughts
'RelatedEntityLocation'
to match the others.ROLE_ALL_LOCATIONS
or ROLE_ALL_LOCATION_DATA
, ROLE_REL_ALL_LOCATIONS
or ROLE_RELATED_ENTITY_LOCATIONS_ALL
SET
to avoid duplicatesCool 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.
@pld @ndegwamartin we can use ROLE_ASSIGNED_LOCATIONS
@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
I'm good with that, makes sense
Keyword Definition
Context
syncLocation
, it will instead fetch the user-assigned location and its children. It will then use this list of location IDs to filter data.syncLocation
, it will fetch the location IDs in the params, fetch their children and use the resulting list to filter the dataTechnical Description of enhancement
syncLocation
param.https://<base_url>/fhir/Patient?_tag=https://smartregister.org/related-entity-location-tag-id|137151
-- Location 1https://<base_url>/fhir/Patient?_tag=https://smartregister.org/related-entity-location-tag-id|136256
--Location 2Acceptance Criteria
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