Enhancing User Experience by allowing place to be replicated with their direct contacts

Hello to the whole team!
Happy New Year to all of you

A few years ago, we created a role to oversee the activities of CHWs. Users could not immediately log into this role due to the huge amount of reports and contacts related to the CHW areas that it needed to synchronize.
To solve this problem, we set the replication depth of this role to 1. This worked well and users were able to log in and send reports.
But this solution came with a limitation.
Setting the role replication depth to 1 forces only places (CHW zones) to be replicated. Direct contacts related to places (CHWs) are not replicated.

Pain points:

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

Expected outcome:
The proposed functionality would introduce a property to help the developer go deeper into role decuments replication.
This could be a property that would help specify whether the directly linked contact can be replicated with the place or not.


1 Like

Thanks for bringing this up @Gilbert! I have some clarifying questions:

Mostly I am trying to understand how your suggestion would differ from setting the Report Depth configuration to something like "depth": 2, "report_depth": 1.

  • Is the concern that also replicating all of the place contact children of the CHW zones (households?) would result in too many documents even if the associated reports are excluded?
  • In your scenario, are there many person contact children of a given CHW zone (or is it usually just one CHW)?
  • Would you want to replicate all the person contact children of the CHW zone or just the primary contact?

and if it were something like “place_depth”:1, “person_depth”:2

1 Like

Thank you @jkuester for your answer,
Yes, setting "depth": 2, "report_depth": 1 would solve part of the problem.

With this configuration, the direct contacts(CHWs) of the place will be replicated, which is desired.

But CHW areas children places (Households) will also be replicated, which is not desired.

We only need the CHW area direct contacts (CHWs) or only the primary contacts if possible.

This configuration will eventually lead to the problem we tried to solve by setting the replication depth because:

  • The target role Place (supervisory area) can contain less or more than 30 places (CHW areas).
  • And each CHW area can contain hundreds of places (households).

Having something like what @bamatic suggests would be nice.

1 Like

Thanks for the clarification @Gilbert and @bamatic! It sounds like there are two possible approaches that might work for this case:

  • Update the default behavior of the replication_depth logic to always automatically replicate the primary contact for a place when the place is replicated. This is nice because it feels logical that if a user has access to a place, they probably also want access to the primary contact. The downside is that it may be confusing to be able to see the primary contact but none of the other contacts at a particular level of the hierarchy.
  • Add new configuration options that allow for configuring different replication depths for place vs person contacts (e.g. place_depth and person_depth). The downside is that this could result in more contact docs being synced than necessary.

@diana do you have any thoughts/feedback on this situation? Is there an alternative solution that we are missing or should we perhaps log a feature request on GitHub?

1 Like

I think we could add a configuration that will allow replicating primary contacts, using the same replication depth. I don’t think this should be the default, since this might be undesirable for some configurations.

Having different configs for places vs people would not be trivial with our approach, 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.

1 Like

Thank you @diana
I agree that adding a configuration for replicating primary contacts could be a solution for that kind of situation

I have logged this feature request on GitHub:

1 Like