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 https://github.com/medic/cht-core/issues/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