Programmatically muting several contacts

Technical Support
1

Hi community, again related to muting
We had some non muted c40_chw_area with some c50_family children muted and others c50_family not muted
We plan to unmute the c40_chw_area and we expect to get all the descendant contacs unmuted, our goal is to restore the former situation
If we take the reported_date of the last mute data_record send with the mute_clinic form as the former value for the c50_families, my plan is to use the POST /api/v2/records to upload mute_clinic data_record in the past, with the reported_date in the past
My questions are

  1. is this a good method to perform this task ?
  2. once uploaded a data_record with form:“mute_clinic” the given c50_family will be muted at the reported_date time?
  3. transition will automatically mute all of membres of the given c50_family ?

Thanks

2

Hi @bamatic

once uploaded a data_record with form:“mute_clinic” the given c50_family will be muted at the reported_date time?

As far as I can tell, the reported_date is not relevant to the muting date - the muting date will be the date when the sentinel transition processed the doc and actually added the muted flag.

unmute the c40_chw_area and we expect to get all the descendant contacs unmuted

If the contact is already unmuted, then the unmute event will have no effect. I think you can trick this process by manually adding a muted: true flag to your c40_chw_area (please verify).

transition will automatically mute all of membres of the given c50_family

correct, all descendents of the muted contact will also become muted.

3

In the https://cht.rci.test.musohealth.app/ running Version 3.15.0

I have created a CHW AREA with
_id:8dc77800-8eac-4f57-9f6e-7518924246b0 name:Z.A. ZUG01 0004
And two c50_family children:
_id:44afa621-5b4d-4515-b77a-735cd78ff74a name:MUTED
_id:7e50eb0a-6dce-4b2f-b2d5-30fa8451a3a1 name:ACTIVE

At 2024-04-17 21:50 approx I mute the MUTED c50_family getting this:
MUTED c50_family

{
_id: "44afa621-5b4d-4515-b77a-735cd78ff74a",
_rev: "4-43598d221818d2f5f12bb00bfe17be3d",
…
type: "contact",
contact_type: "c50_family",
reported_date: 1713390186626,
place_id: "1972704",
muting_history:
{
server_side:
{
muted: true,
date: "2024-04-17T21:50:05.009Z"
},
client_side:
[
{
muted: true,
date: "2024-04-17T21:50:01.762Z",
report_id: "34de766d-37c6-4447-8056-09f3af3551b2"
}
],
last_update: "server_side"
},
muted: "2024-04-17T21:50:05.009Z"
}

At 2024-04-17 21:55 approx I mute the Z.A. ZUG01 0004 c40_chw_area getting this:
For the MUTED c50_family

{
_id: "44afa621-5b4d-4515-b77a-735cd78ff74a",
_rev: "4-43598d221818d2f5f12bb00bfe17be3d",
name: "MUTED",
type: "contact",
contact_type: "c50_family",
reported_date: 1713390186626,
place_id: "1972704",
muting_history:
{
server_side:
{
muted: true,
date: "2024-04-17T21:50:05.009Z"
},
client_side:
[
{
muted: true,
date: "2024-04-17T21:50:01.762Z",
report_id: "34de766d-37c6-4447-8056-09f3af3551b2"
}
],
last_update: "server_side"
},
muted: "2024-04-17T21:50:05.009Z"
} //here is working as expected

For the ACTIVE c50_family (no muting_history)

{
_id: "7e50eb0a-6dce-4b2f-b2d5-30fa8451a3a1",
name: "ACTIVE",
type: "contact",
contact_type: "c50_family",
reported_date: 1713390080071,
place_id: "5896551",
muted: "2024-04-17T21:55:02.718Z"
} //here I do not know if the c50_family should have a muting_history

For the Z.A. ZUG01 0004 c40_chw_area:

{
_id: "8dc77800-8eac-4f57-9f6e-7518924246b0",
_rev: "5-c731a4230b148735fb8b587a10e27674",
type: "contact",
name: "Z.A. ZUG01 0004",
contact_type: "c40_chw_area",
reported_date: 1713389971570,
place_id: "5227239",
muting_history:
{
server_side:
{
muted: true,
date: "2024-04-17T21:55:02.320Z"
},
client_side:
[
{
muted: true,
date: "2024-04-17T21:55:00.941Z",
report_id: "905cb0cf-fbe9-4df8-8b6f-5230e9752c03"
}
],
last_update: "server_side"
},
muted: "2024-04-17T21:55:02.320Z"
}

At 2024-04-17 22:10 approx I unmute the Z.A. ZUG01 0004 c40_chw_area getting both families unmuted:

For the MUTED c50_family

{
_id: "44afa621-5b4d-4515-b77a-735cd78ff74a",
_rev: "5-55d698243117f082ab47a0548ef5ffa2",
name: "MUTED",
type: "contact",
contact_type: "c50_family",
reported_date: 1713390186626,
place_id: "1972704",
muting_history:
{
server_side:
{
muted: false,
date: "2024-04-17T22:10:13.338Z"
},
client_side:
[
{
muted: true,
date: "2024-04-17T21:50:01.762Z",
report_id: "34de766d-37c6-4447-8056-09f3af3551b2"
}
],
last_update: "server_side"
}
}// do not understand why the first mute disappears from the muting history

For the ACTIVE c50_family (no muting_history)

{
_id: "7e50eb0a-6dce-4b2f-b2d5-30fa8451a3a1",
_rev: "4-fb199ce0684f579b4bd75300c56de5d6",
name: "ACTIVE",
type: "contact",
contact_type: "c50_family",
reported_date: 1713390080071,
place_id: "5896551"
}// like just nothing has happened

For the Z.A. ZUG01 0004 c40_chw_area:

{
_id: "8dc77800-8eac-4f57-9f6e-7518924246b0",
_rev: "7-6436b2a65e453761249c504cc9419953",
type: "contact",
name: "Z.A. ZUG01 0004",
contact_type: "c40_chw_area",
reported_date: 1713389971570,
place_id: "5227239",
muting_history:
{
server_side:
{
muted: false,
date: "2024-04-17T22:10:13.338Z"
},
client_side:
[
{
muted: true,
date: "2024-04-17T21:55:00.941Z",
report_id: "905cb0cf-fbe9-4df8-8b6f-5230e9752c03"
},
{
muted: false,
date: "2024-04-17T22:10:11.748Z",
report_id: "3780d132-4140-42c6-bd3e-2f3f46749ad1"
}
],
last_update: "server_side"
}
}// this makes sense for me
4

For muting_history:

  • There are two types of muting events: events that happen on the server and events that happen on the client.
  • the server does not add the muting_history, only the client does. So if your contact is only ever muted/unmuted by the server, it will not have the muting_history property
  • the server section of the muting_history does NOT contain a list of all muting events that happened on the server, just the last event. For server-side muting events, you can check infodoc for that.

I am unclear of your hierarchy here, and what unmute is, but a muting event by senting an SMS will have different effect to a muting event done in app, and even then it will depend on which user executes the muting event - because the contacts that they “see” get muted on the client (and get the muting_history entry), and the contacts they do not see get muted on the server, once the muting report is processed by sentinel.

muting_history is used internally to keep track of what happened on the client when the server runs a muting event that had already been processed client-side.

5

Thank you for your answers
c50_family is child of c40_chw_area and c40_chw_area is a child of c30_supervisor_area
in config setting we have

 "muting": {
    "mute_forms": [
      "mute_patient",
      "mute_clinic",
      "mute_chw_area"
    ],
    "unmute_forms": [
      "unmute_patient",
      "unmute_clinic",
      "unmute_chw_area"
    ],

By “to mute” I mean to send a mute_form for a contact, and by “to unmute” to send an unmute form.

I’ve started with this situation, a c40_chw_area with 3 childre, a person child, and two c50_family children,

last
last410×596 16.5 KB

With the app and connected with a user attached to the c40_chw_area I have send a mute_form from the contact page of the c50_family nalmed MUTED, so I’ve get one c50_family muted and the other not muted

first
first396×630 17.6 KB

With the app, connected with a user attached to the parent of the c40_chw_area, and depth 1, this user sees c40_chw_areas but not c50_families, once on the c40_chw_area parent contact, I’ve sent a mute_form, so all its descendants have been muted

second
second452×651 19.7 KB

finally, With the app, connected with a user attached to the parent of the c40_chw_area, and depth 1 I’ve send an unmute_form from the contact page of the c40_chw_area and all the descendants have been not muted
last
last410×596 16.5 KB

I expected to have the c50_family called MUTED with a non null value of the muted json property but both c50_families have been unmuted

6

With the app, connected with a user attached to the parent of the c40_chw_area, and depth 1 I’ve send an unmute_form from the contact page of the c40_chw_area and all the descendants have been not muted

I expected to have the c50_family called MUTED with a non null value of the muted json property but both c50_families have been unmuted

If the c50_family is a child of c40_chw_area that you have just unmuted, then it’s expected for it to also be unmuted. With depth 1 for the user that sends the muting request, this means that the client will add muting_history only for the contacts that this particular user can see, and all the other descendants would be changed server-side (and they will not have client-side muting_history, only the one updated entry for server).

7

if the chw area supervisor that is attached to the chw area parent’s place, cannot access families, the children of the chw area, because of the depth 1, it is not possible to add a mute history to the c50_families so the c50_family named ACTIVE, won’t have a muting history at all.

In the case of the c50_family named MUTE, it has the first mute of the chw that is attached to the parent of the c50_family, so this appears in the client side mute, so once on the server, the sentinel transition will mute this, server side
when the chw supervisor attached to the parent of the c40_chw_area, tthis is the grand parent of the c50_family, mutes the c40_chw_area, this won’t affect client’s mute history of the MUTE family because the depth is 1, in addition, in the server side, since the c50_family is already muted, the c40_chw_area’s mute form submission won’t have effects, when the c40_chw_area’s unmute form is submitted, in the client side, this has no effets, depth is 1, but in the server side since the c50_family is muted , server side will change and will be unmuted. is this ?

Sometimes questions like “was this family muted in this X date” are difficult to answer since some muting from parents are server side and they depend on family state, (muted or not muted), and the state is that we are finding.
Maybe to have also a server side mute history could help.

8

Maybe to have also a server side mute history could help.

The infodoc should contain the server-side muting history. You can find this doc in medic-sentinel under with a uuid like <contact_uuid>-info.

the scenario you describe is pretty complicated and I have trouble following it, specifically when you say things like:

in addition, in the server side, since the c50_family is already muted, the c40_chw_area’s mute form submission won’t have effects,

if c50_family is muted, then the server will mute all of its descendants, meaning that c40_chw_area is also already muted. Or is this a case where one user mutes c50_family and doesn’t sync, and another user mutes c40_chw_area and doesn’t sync, and then both these muting events need to be reconciled?