Add config to allow replicating primary contacts for places at max depth

[jkuester]

Is your feature request related to a problem? Please describe.
When using the replication_depth configuration, the places at the max depth will be replicated, but not the person associated with that place. For example, a CHW Supervisor may be configured to only have access to the CHW Areas (but not the actual CHW person contacts related to the areas).

Pain points:

• The logged-in user has no information about the place-related contact they are monitoring.
• Users are forced to use a notebook to match the place with its primary or related contact.
• The place-related contact is not available when creating tasks or goals.

Currently, the only way for the supervisor to have access to the CHW is to increase the replication_depth. However, that would also give the supervisor access to all the other contact children of the CHW Area (e.g. households) which could cause performance issues.

Describe the solution you'd like

It would be useful to have a configuration option that will allow replicating primary contacts, using the same replication depth. So, if the config option is set, then the primary contacts for places at the max depth would also be replicated.

Describe alternatives you've considered

Another option is to just make this the default behavior so that primary contacts are always replicated whenever a place is replicated.

A separate approach would be to to support configuring separate replication depths for places and persons (e.g. place_depth and person_depth). This would not be easy to implement because we use a view which is unaware of whether a contact is a place or person, since we can’t inject configurable hierarchy contact types in the view. This means that we’d need to edit the view to emit the contact type, and, in code, we would query for every contact type for every level instead of one query just by level. This adds complexity and potentially impacts performance because of the additional queries that are needed.

Additional context
Originally submitted on the CHT Forum.

[jonathanbataire]

This is similar to #7156

[Marina-Kenf]

Looking forward to having this feature that MoH Mali's Supervisor workflow will also benefit from - cc @loukmantidjani

[jkuester]

Discussed this in more detail with @dianabarsan and @mrjones-plip. Here are some current thoughts:

• Any implementation of this feature will require changes to the logic for determining which docs are replicated for a user
• Currently there are two ideas on how to update that logic:
  • Update the contacts_by_depth view to also emit the parent._id for the contact and then include this id in the list of subject ids when retrieving the reports.
    • The query to retrieve reports for subjects is already very heavy and this will make it worse by significantly increasing the number of subject ids included in the query (number_of_places * 2)
    • This would make it so the primary contact's are "writable" for the user and the user can submit reports for that contact.
    • It should be possible to update the view in a way that will not impact deployments that do not choose to enable this functionality.
  • Alternatively, it would be possible to have separate logic to deal with getting the primary contacts for places when the user is replicating, but NOT including those extra people in the list of subject ids when retrieving the reports.
    • In this case the performance impacts could be minimized, but users would NOT be able to submit reports for these additional contacts (they would essentially be "readonly")

Next steps:

• We need more information about the specific workflows we want to support with this functionality
  • How are user's impacted by the current behavior?
  • What benefits do we expect to see from a different behavior?
  • How important are those benefits? (e.g. is the functionality crucial enough that it would be worth significantly increasing the amount of docs replicated to a user's device?)
• @mrjones-plip is going to help setup some follow-up conversations to drill in on some of these questions.

[jonathanbataire]

Any update on this issue? this really affects performance of supervisor views in CHT looking forward to having it prioritized. Thanks cc @craig-landry

[dianabarsan]

A new request came through, regarding supervisors with depth=1 is to see CHW target aggregates, which right now is not possible without downloading the CHW contact and targets associated with them.
Forum thread link

This means that the contact would need to get into the "reports" request - because that is the request that yields the target documents.

[dianabarsan]

Investigation from yesterday resulted in:

1. 😁
   Changes to contacts_by_depth are required, but the change won't alter the size of the view, because we are only changing the emitted value, not adding extra emissions

2. 😢
   Changes to contacts_by_depth are insufficient, due to how we implement performance improvements in various endpoints, where we assume that we can validate whether a user has access to a contact doc without getting all their available subjects. This is true because all data required existed in the doc, their lineage. Unfortunately we don't have information about whether this contact is primary to some place, and there is no enforced rule that a contact can only be primary to a parent or grandparent.

We would need to:

• 😢 add a view that indexes by primary contact, and query that view to get a list of places that a contact is primary of
• 😁😁 enforce that we will only replicate primary contacts if they are primary for a place within their lineage. Then we will add one extra query to our O(1) db-get requests that will also get the doc's lineage, and run the same O(1) check over the parents.

I'm curious to see how frequent it is to have a primary contact of a place that is not within that place.

[dianabarsan]

Since this has many open questions, I'm removing this from 4.14 and bumping to 4.15.