Add the syncLocation request params to all GET requests when using the sync by Related Entity Location -> User Selected Location sync strategy

[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.
• The Sync Locations will be part of the request parameters. These will be found on the syncLocation param.
• This ticket is to add the ability to create and add the syncLocation param to the GET request from the data stored in the secure shared prefs on the app.

Technical Description of enhancement

• If the app sync strategy is REL, during login check if the user has the ROLE_VALIDATE_ASSIGNMENT keycloak ROLE. if the user does not have this role then add the syncLocation request param to the GET requests while fetching data.
  • We can store a true or false on the secure shared prefs for the above check.

Acceptance criteria

• All GET requests from fhircore should have the syncLocation request param if the user has the ROLE_VALIDATE_ASSIGNMENT keycloak ROLE

Implementation plan (For Engineers)
The plan for implementing the solution e.g. via a description or a check list for the various ordered tasks that will need to be completed.
i.e. Describe how you intend to solve the problem

[pld]

Client Location seems misleading as the sync strategy, because if ClientLocation.userAssignedLocation == false then isn't your' sync strategy not the client location?

But instead, more generally, the strategy is by location? And, even if it isn't true, can we still send the syncLocation param, but have it be the logged in users assigned location, to match how it works now?