Add a list of datapoints to the device assignment endpoints

[muloem]

As part of the work done under assignments reimplementation #2796, we will enable selection of a list of datapoints that will be assigned to a specific device for monitoring exercises. It means that device will only be limited to downloading those datapoints assigned to it.

This requires reimplementing the backend APIs used to retrieve assigned forms, to also include a list of datapoint IDs so the device knows which datapoints it can actually download.

Some issues to decide:

• An alternative would be to include the datapoints when downloading the assignments but this may be a bit problematic if there are loads of datapoints.

• Should we implement a completely new endpoint that returns JSON rather than modifying the current API for assignments that uses a rather complicated custom format for returning assignments lists?

@valllllll2000 @stellanl Could you sync and talk about this one?

[muloem]

Some other things to consider:

• when a device creates a new datapoint that has not yet been synced to the backend, should we automatically add this datapoint to the list of those assigned to this device?
• When a datapoint is assigned to a device and then later unassigned, what do we do on the device end? Do we remove this datapoint from the device?

@janagombitova what do you think?

[janagombitova]

when a device creates a new datapoint that has not yet been synced to the backend, should we automatically add this datapoint to the list of those assigned to this device?

Thinking out loud:

• Salim assigns the existing data points to Al and Joe. > Al and Joe download the points they have assigned and Al also creates 5 new points. If he hits download again, these 5 new points will not go to Joe, as they are not assigned to her, but they will stay on Al's app, right? (that is how things work today, we do not remove points) In this case for Al it does not matter if his 5 new points are assigned to him or not, as he can collect monitoring data for them.
• Because he can collect monitoring data for the points he created, they should then be automatically assigned to him.
• Following this path, how will Salim know which are the new points when he looks at the assignments that we 'auto-assigned' to Al? If we can solve this, then I think for the 1st iteration we can auto-assign to Al, what Al has created.

When a datapoint is assigned to a device and then later unassigned, what do we do on the device end? Do we remove this datapoint from the device?

• We should remove data points that were unassigned from the device. It means Al should not have these points anymore.
• Also, following the thinking in the point above, if we auto-assign and then Salim removes the points from Al, then we should also remove them from the device.

But:

• What would happen if forms that are submitted to an unassigned data point are not synced yet? We need to ensure all data is in, before we remove it from the phone.
• Would this also mean that once a simple form assignment (without datapoint) that is deleted will also result in removing the forms from the device? Or if a device is removed from an assignment that the forms will also be removed from the device?

Considering these questions, I would leave this to a 2nd iteration. But I do believe removing from the device what is unassigned will:

• enforce the idea that an assignment is a task
• gives Salim more control in regulating who has access to what in the field
• reflects some of the user feedback we have been receiving about assignments

[stellanl]

A fundamental design decision is whether a data point is assigned to a maximum of one device at a time:

• If it is max one, we can save that in the DP itself.
• If it can be assigned to more than one, that data belongs in the assignment, and we will need one assignment per (group of devices with identical DP assignments).

[janagombitova]

@stellanl the expectation is that a data point can be assigned to more than one device.

[stellanl]

Ok, then we can either:

1. Create separate "DP assignments" as a new entity type, organised as children of the current "Form assignment". Seems like the cleaner model.
2. Split the assignment so there is one per (group of devices with identical DP assignments). This will require something to "glue" the various assignments together. Just having the names be identical leads to a lot of possible ambiguities.

[stellanl]

Initial implementation:

New datastore entity Kind: DataPointAssignment with these fields:

Long surveyAssignmentId
Long deviceId
List<Long> dataPointIds
Long surveyId

The REST endpoint is /rest/data_point_assignments

Also, SurveyAssignment has a new field:
Long surveyId

In both cases, surveyId is the survey (UI survey, SurveyGroup, not form) that the assignment is for.

For the app there is a new endpoint, /assigned_datapoints. See #3167

[stellanl]

Since we will run a data script #3107 to split any assignments into survey-specific ones, we can modify that slightly to populate the surveyId field at the same time.

[stellanl]

As we are changing the API, and processing all the existing assignments, we could take the opportunity to rename survey to form in both the survey-assignment rest API and the datastore.
There should be no impact on the Lumen-visible stuff.

[janagombitova]

Is there anything user-visible to test here?

[janagombitova]

All linked PRs are merged and released. If this still needs work - please reopen