Provide children contacts of current contact to contact-summary calculation

[jkuester]

Is your feature request related to a problem? Please describe.
When calculating the contact summary for a place, it would be useful to be able to include data about the child contacts of the place in the calculation. (E.g. to show a warning if the number of contacts does not match what is expected). Currently, there is no way to access any information about those child contacts.

Describe the solution you'd like
In webapp, when we have a contact in context (e.g. we are viewing that contact's profile page), we have already done the heavy lifting to look up the contact's children. (This involves finding which contact types are valid children of the current contact and then querying medic-client/contacts_by_parent for each of the types.) We only calculate the contact-summary when we have a contact in context, so I do not think adding support for this functionality would negatively impact performance (except perhaps when loading a form for a task. I believe we are currently calculating a the contact-summary in that case, but we might not have the children loaded already...)

Describe alternatives you've considered
We could rework our contact hierarchy model to be doubly linked so contacts contain the _ids both for their parent and their children. Seems like that would cause more trouble than it would resolve....

[garethbowen]

@jkuester Sounds good to me! It'd be worth doing a sanity check on performance to make sure it's not adding much of a lift, but otherwise, good to go!

[jkuester]

@garethbowen after taking a deep dive into the code here and what it would take to make sure we have the contact children everywhere that we are currently calculating the contact summary, I have confirmed that we would need to add an additional call to medic-client/contacts_by_parent each time we open an app form either from a contact profile page or from a task. This is the only way we could guarantee we have up-to-date data about the contact's children.

Let me know if you think this qualifies as "much of a lift"! On one hand, the view query should be pretty straightforward and efficient. On the other hand, I know that we are already pretty sensitive about the form opening times and this will def not improve that. But, on the other hand, we would be able to do the query simultaneously with these other three lookups that we are already doing for the contact:

• getting all the contact's reports
• getting the contact's lineage
• getting the contact's target docs

These 4 things would all be happening at the same time and it seems unlikely the new query would be any slower than medic-client/reports_by_subject. 🤔 🤷

[dianabarsan]

happening at the same time

Unfortunately, the indexeddb adapter is single-threaded and queues all requests.

pretty sensitive about the form opening times

I agree this is not a heavy duty query. There are no free features.

[garethbowen]

The performance should be ok for families (though let's test to make sure). We will need to think about if we also need to do this looking further up the tree where there could be hundreds of children.

[jkuester]

We will need to think about if we also need to do this looking further up the tree where there could be hundreds of children.

The more I think about this, the sketchier it gets... On one hand, these are the same lookups that we do when loading a contact's profile page. So loading times might not be great, but it should not be prohibitively bad. However one big caveat here is that I believe the contact children for the profile are paged lookups (so we are only getting 50 at a time or something). Where as I feel like we really need to pass all or nothing here when it comes to the children. (I don't want to run into the same issue we did with the reports where only a subset was available to the contact summary calculation....) This seems to change the equation such that the ceiling for how bad the loading time might be for contacts with lots of children is much higher.

IDK @garethbowen it almost feels like it would be better to solve the problem of running async code in the contact-summary logic. Then we would not have to pre-load children for every contact, but the contact summary config code would have access to the cht-datasource and could load the children if needed. 🤔 I have logged #9623 to give this possibility a closer look!

[garethbowen]

Yeah I think you're right. Otherwise we end up doing more and more preloading before calling the function without even knowing if it's going to be used.

[latin-panda]

Moving it to 4.16

[jkuester]

Just removing the release milestone for now. I believe this issue will be best address by #9623