Closed f-odhiambo closed 2 years ago
From @fredhersch
Current approach: client constructs the query and sends to the HAPI restful end-point to perform an operation
Versus:
Does the SDK just point to an API end-point (passing in the authenticated user) that performs the operations server-side to determine what patients and resources the client should have access to?
The later makes sense to me because the server is what knows about permissions, and I believe that's what we're doing now.
@Andati @rkodev can you describe if this aligns w/what we're doing now?
CC @mberg
We need to coordinate with Google on this to flesh it out and figure out a strategy on sync. From this week's call, it seems like they would need our input.
Related to #42
FhirEngine#syncUpload
. This gets all the local changes on the database and syncs to the server
LocalChangeEntity
for a single resource by timeline so that the latest changes are always on the right during the reduce
function. Basically remove the possibility of new data being replaced with older data when squashing multiple changes made on a single Resource.periodicSync
only downloads periodically but needs to also upload first before downloadingCurrently handled byFhirEngine
and periodicSync
FhirEngine
initialization, it triggers an initial download followed by scheduled subsequent syncs(data downloads) based on the SyncConfiguration
timing. The downloads happen periodically based on the sync configuration.SyncData#LAST_UPDATED_KEY
similar to SyncData#LAST_UPDATED_ASC_KEY
?SyncConfiguration
. This will require a discussion on this and modification of android-fhir
SyncConfiguration
almost directly imitates the current OpenSRP filter functionality. It provides syncing of each resource type from a date X ordered by the last-updated-key. However, the SyncConfiguration
requires a "location mapping" filter and the HAPI FHIR server should perform an authorisation and authentication check for each request. The server can also add extra filters depending on the user's authorisationSyncConfiguration
and update it in case the user changes their current focus location/care-team/organisation or their assignment changesSyncConfiguration
to support custom resource property filtersSyncConfiguration
with the appropriate filters, resource types to sync and timing between periodic syncsFHIREngine#syncUpload
as the first call during periodic sync in FHIR to ensure upload happens before the downloadandroid-fhir
upload functionality that would case loss of data and upload of data in the wrong chronological order - Possible bug when squashing of multiple local changes on a single resource during uploadandroid-fhir
to bulk upload resources. HAPI FHIR server allows bulk uploading by resource typeWe can send a batch request by grouping by Resource Type
and Request Type
, the ordinality of the group can be determined combination of all POST
requests = 0 and everything else = 1 + and the minimum change in the set of resources.
On the event downloads not exactly sure why the order will matter since the SDK seems not to care about the downloads, my understanding from the codebase looks like all data is saved regardless of the relationship and as long as sync is complete there will be Eventual Consistency.
On Sync : Option 4 We can implement a custom interceptor for Retrofit, this is assuming the sync params are simple might not need any changes to the SDK side
General comment: I think adding access control on the server-side instead of only relying on the client as we currently do in OpenSRP will great.
@rkodev I have updated the strategy based on your recommendations
@rkodev what do you mean by:
I think adding access control on the server-side instead of only relying on the client as we currently do in OpenSRP will great.
How does the client perform access control on OpenSRP?
@vincent-karuri the older implementations of OpenSRP would return data without performing an authorization check to check whether the user requesting the data has access to the data. The server relied on OpenSRP clients to request only the data the client has access to i.e provide the filter parameters
Currently blocked by location mapping tasks
what's remaining here?
LocalChangeEntity
to confirm that new updates are not ignoredWe probably want to change this issue into a discussion
Great to see the progress here.
Couple of questions:
I have updated my comment and updated the details also
@fredhersch @ekigamba Yes. This is what we want to achieve with the Single APK approach. We will also tie in Keycloack to facilitate Role-Based access control (RBAC). Also, we have the location hierarchy (Sync Location/Team) piece that will aid in unblocking this once done i.e. #188 & #189
Lastly, converting this to a discussion point
Save questionnaire resource to SQLite DB and ensure it syncs to FHIR server
For ANC App