We require CHWs to have the ability to delete hierarchy items (plots/households/household members) when they are no longer relevant or have been created in error.
Unfortunately, we have encountered a scenario where a CHW accidentally deleted themselves. There is also a real possibility of accidentally deleting other CHWs and impacting their work.
Is there a way to conditionally show the ‘delete’ option to the user only when they are on certain levels of the hierarchy?
As far as I can tell from the code there is no way to control what contacts a user can delete. Clearly this is not ideal (and it is a serious challenge that user contacts could be accidentally deleted). I have logged a new issue for this:
Please feel free to add any additional context or details to the issue! One clarification that would be helpful here is if you could include some info abut the workflow(s) where the CHW users need to have the can_delete_contact permission. Thanks!
Just to be clear, are you talking about online or offline users? The reason I ask is that offline users normally can’t see (and therefore can’t delete) other CHWs at the same level in the hierarchy (ie “peers”). Perhaps you could describe your hierarchy as well. Thanks!
The CHWs are offline users.
That’s interesting, as in our runs the CHWs have always been able to see their peers.
See below screenshots where I logged in as a test CHW:
Do you believe this could be a fundamental fault in our hierarchy?
Our hierarchy structure is as follows
Our hierarchy in code:
"place_hierarchy_types": [
"npo",
"team_area",
"indawo",
"dwelling",
"household"
],
"contact_types": [
{
"id": "npo",
"name_key": "contact.type.npo",
"group_key": "contact.type.npo.plural",
"create_key": "contact.type.npo.new",
"edit_key": "contact.type.place.edit",
"icon": "wcg-npo",
"create_form": "form:contact:npo:create",
"edit_form": "form:contact:npo:edit"
},
{
"id": "dho",
"name_key": "contact.type.dho",
"group_key": "contact.type.dho.plural",
"create_key": "contact.type.dho.new",
"edit_key": "contact.type.dho.edit",
"primary_contact_key": "contact.type.dho-primary",
"parents": [
"npo"
],
"icon": "wcg-dho",
"create_form": "form:contact:dho:create",
"edit_form": "form:contact:dho:edit",
"person": true
},
{
"id": "team_area",
"name_key": "contact.type.team_area",
"group_key": "contact.type.team_area.plural",
"create_key": "contact.type.team_area.new",
"edit_key": "contact.type.place.edit",
"parents": [
"npo"
],
"icon": "wcg-team_area",
"create_form": "form:contact:team_area:create",
"edit_form": "form:contact:team_area:edit"
},
{
"id": "team_lead",
"name_key": "contact.type.team_lead",
"group_key": "contact.type.team_lead.plural",
"create_key": "contact.type.team_lead.new",
"edit_key": "contact.type.team_lead.edit",
"primary_contact_key": "contact.type.team_lead-primary",
"parents": [
"team_area"
],
"icon": "wcg-team_lead",
"create_form": "form:contact:team_lead:create",
"edit_form": "form:contact:team_lead:edit",
"person": true
},
{
"id": "indawo",
"name_key": "contact.type.indawo",
"group_key": "contact.type.indawo.plural",
"create_key": "contact.type.indawo.new",
"edit_key": "contact.type.place.edit",
"parents": [
"team_area"
],
"icon": "wcg-indawo",
"create_form": "form:contact:indawo:create",
"edit_form": "form:contact:indawo:edit"
},
{
"id": "chw",
"name_key": "contact.type.chw",
"group_key": "contact.type.chw.plural",
"create_key": "contact.type.chw.new",
"edit_key": "contact.type.chw.edit",
"primary_contact_key": "contact.type.chw-primary",
"parents": [
"indawo"
],
"icon": "wcg-chw",
"create_form": "form:contact:chw:create",
"edit_form": "form:contact:chw:edit",
"person": true
},
{
"id": "dwelling",
"name_key": "contact.type.dwelling",
"group_key": "contact.type.dwelling.plural",
"create_key": "contact.type.dwelling.new",
"edit_key": "contact.type.place.edit",
"parents": [
"indawo"
],
"icon": "wcg-dwelling",
"create_form": "form:contact:dwelling:create",
"edit_form": "form:contact:dwelling:edit"
},
{
"id": "household",
"name_key": "contact.type.household",
"group_key": "contact.type.household.plural",
"create_key": "contact.type.household.new",
"edit_key": "contact.type.household.edit",
"parents": [
"dwelling"
],
"icon": "wcg-household",
"create_form": "form:contact:household:create",
"edit_form": "form:contact:household:edit",
"count_visits": true
},
{
"id": "hhm",
"name_key": "contact.type.hhm",
"group_key": "contact.type.hhm.plural",
"create_key": "contact.type.hhm.new",
"edit_key": "contact.type.hhm.edit",
"primary_contact_key": "contact.type.hhm-primary",
"parents": [
"household"
],
"icon": "wcg-hhm",
"create_form": "form:contact:hhm:create",
"edit_form": "form:contact:hhm:edit",
"person": true
}
]
The CHWs would need deletion permissions on the Location/Plot, Household, and Household member levels.
Location/Plot:
Household:
Household member:
This would help the CHWs delete entries that were captured in error, or delete entries that are no longer of relevance - adhering to training.
We’ve recently become aware of quite a few duplicate captures, which we believe was caused in part by the 50 contact limit bug we had on our CHT instance (since been resolved).
We’re updating our training to include the usage of the search bar, to also help mitigate such captures.
That being said, giving the CHW the ability to correct incorrect captures early on would help significantly.
Since you have multiple CHWs associated to the same Indawo, it makes sense as to why they would see their peers now, because they have the same parent. I think it’s more common to see each CHW have their own parent. It’s totally fine the way you have it but of course there’s a bigger risk of multiple CHWs editing the same document.
The thing that does look a bit odd to me though is the order in which things are showing up on the left side list on the Contacts tab.
In your hierarchy, indawo is above (ie parent of) dwelling, but in the screenshot “Indawo” is below your “Plots” (dwelling). That doesn’t look right to me… what do you think @jkuester @Jennifer_Quesada? I just tested on 4.5 and even when you “Sort” alphabetically, the user’s place is always at the top of the list.
Thank you for clarifying. Our usual approach is 1 CHW per parent (Indawo), however there are cases where a CHW is accompanied by another CHW due to safety reasons or simply because they operate in pairs.
I do appreciate highlighting the risks of editing the same record. For interest sake, how would the system handle such an occurrence?
That’s a good point, I have not noticed it before.
Investigated this by logging in as a dho, team lead & CHW. On first glance it seemed as if only the dho’s place ordering is being respected. However, when toggling between “Alphabetically” and “By date last visited” in the search bar, seems to switch some of the place positions.
We’re currently on CHT version 4.2.2, has this “fixed parent” item been only implemented on later versions?
Default views:
Switch ordering:
Version:
Regarding the order of contacts in the sidebar, I did not see anything in the release notes since 4.2.2. that would indicate a change to the ordering, but I will defer this question to @Jennifer_Quesada who def has more visibility on any changes that have recently happened in this part of the code (and the expected behavior in general).
The short answer here is that if a document is located on two separate offline devices and both edit the same document while offline and then try to sync the changes to the server, the server will mark the doc as having a conflict and then pick one of the versions to use going forwards. Crucially, the version of the doc that the server picks as the “correct” one will get synced back to both client devices. So, after a successful sync, the same version of the document will be reflected on both client devices and on the server (and the changes from one of the users will not be seen anywhere). This approach emphasizes data consistency at the cost of “hiding” conflicting changes from the view of normal users.
It is possible to view all the docs that have conflicts (to determine if manual intervention is needed to recover hidden data). In Fauxton you can use the conflicts view in the medic-conflicts design to list all the docs with conflicts (open this Fauxton path for your CHT instance: _utils/#/database/medic/_design/medic-conflicts/_view/conflicts).
Also, regarding how Couch “picks” a version to use, the Couch docs say:
CouchDB picks one arbitrary revision as the “winner”, using a deterministic algorithm so that the same choice will be made on all peers.
I do not know the details of the algorithm, but from experience with docs that have a conflict on just a single field (e.g. the contact’s name field was updated on both devices), the chosen “winner” was the version that was synced to the server first.
I have seen the hierarchy order issue on another project. Oddly enough, it only happens to the CHWs; The order is fine for all other user types.
Hi @Femi do you have more information about the project where you saw the heirarchy order issue ?
Perhaps the CHT version they are on?
Their heirarchy ?
I am trying to reproduce it and figure out whether there is a bug somewhere in the code or whether it is a configuration issue.
Thank you.
