Cht-core: Moving contacts doesn't update the contact who will receive scheduled messages when no patient_id is set.

[newtewt]

Describe the bug
We introduced the option to move contacts to new parents in medic-conf. When a report is missing the fields.patient_id the doc won't update correctly to the new parent. This causes the scheduled messages to be sent to the previous contact who submitted the report originally. This would need to be updated so that it send to the correct contact under the new parent.

To Reproduce
Steps to reproduce the behavior:

1. As an offline user. Go offline
2. Create a new female patient with standard config
3. Process a new pregnancy(this report should have no fields.patient_id because it is offline and sentinel hasn't given the patient_id)
4. Go online and sync.
5. Move the newly created patient to a new parent.
6. Review the scheduled messages

Expected behavior
The scheduled messages should be updated to the new correct contact so when they are sent it is sent to the correct person. They currently will send to the original reporter.

Environment

• Instance: gamma.dev
• Browser: chrome
• Client platform: linux
• App: webapp
• Version: 3.6.0

Additional context
From @dianabarsan

When hydrating a single doc (with fetchHydratedDoc) we end up with the fully hydrated patient lineage, including the primary contacts of the parents, but when fetching in bulk (with hydrateDocs) we end up with minified patient primary contacts lineage, which is required to map patient clinic correctly. The bulk hydration is used when scheduled messages are generated

[tookam]

@garethbowen It looks like the primary contact could be referenced in many documents (reports) but not updated (ex: pregnancy report). I am wondering if we need to replace all these references (name, id). What do you think?
@kennsippell you may have an opinion since you worked on the initial implementation of move-contacts.

[garethbowen]

I think you should not be able to move a contact if they are a primary contact for the place (unless you are also moving that place). The primary contact of a place that you're not moving shouldn't be automatically updated because we don't know who to pick as the primary.

I'm wondering if that's the issue though - I haven't looked at the code but it sounds like the patient is being moved but the message is being sent to their _old_ contact not the new one.

[kennsippell]

From @dianabarsan's "context" above, it sounds like she suspected a bug in how we hydrate contacts, and not a bug in the move-contacts implementation... That said, I suspect a reasonable fix here might be to update the move-contacts script to not allow moving contacts without an assigned patient_id (must wait for sentinel).

[dianabarsan]

@kennsippell is right, the main bug is that our lineage shared library doesn't perform the bulk hydration correctly. This affects other functionality as well, for example incorrectly mapping recipients when processing scheduled messages.

The reason why this bug was discovered in correlation to moving contacts was because it generated a report that had scheduled messages configured to be sent to someone from the patient's lineage, while the original report was created by someone outside the patient's lineage. When the scheduled messages became due and were generated, the recipient was incorrectly mapped to the original sender instead, because patient lineage was not fully hydrated.
You can replicate this without actually moving contacts.

[kennsippell]

Found another issue while fixing this one https://github.com/medic/medic/issues/5897

[dianabarsan]

Ready for AT on 5824-lineage-patient-easy.

This bug did not only affect reports about contacts that were moved, rather any report that satisfied these conditions:
a. The configured recipient is someone in the patient's lineage (like grandparent or clinic)
b. The sender(submitter) is someone who is outside the patient's lineage (could even be anonymous, if SMS and your form is public).
The lineage library was refactored as part of this change, please also check that contact-summary receives correct information, in general SMS messages have correct recipients, etc.

[ngaruko]

Not sure if I understood what changed in this issue @dianabarsan but I seem to see the same behaviour on the branch>

1. have two district: bede & ngaruko's district with bede & ngaruko as respective contact
   2 . add a person to bede's district
2. create a pregnancy report for the person
3. move the person to ngaruko's district
4. check report => messages are still scheduled to be sent to bede's number ...

[dianabarsan]

@ngaruko
Can you please repeat the test with a patient at clinic level: move them from one clinic (that has a contact with a valid phone) to another clinic (that has a contact with a different valid phone).
If you're using standard config, the ANC Reminders are set to send messages to clinic (https://github.com/medic/medic/blob/master/config/standard/app_settings.json#L3190) which, in the case of a district level patient, will not resolve and default to the submitter.

[ngaruko]

Thanks @dianabarsan Scheduled messages go to the new contact if they are at clinic level. Not sure if this was meant to be covered in the ticket: the patient's parent in the report still shows the old parent:
ie
on contact page:

but on the report (original clinic):

[dianabarsan]

@ngaruko
This issue only covers correcting how report lineage is hydrated, thus resolving that correct "clinic" phone number when the contact is moved.

Updating _possibly_ static fields in reports (like CHW Name and CHW Phone Number) would be part of the original "move contacts" issue (https://github.com/medic/medic-conf/issues/172). I believe it was not intended for those fields to be updated. Are you requesting they should?

[ngaruko]

Agree @dianabarsan . That was not covered with the issue. I will close this and leave updating the other fields for another conversation...