Is it possible to move a PLACE in any other way except using the cht-conf tool’s contact-move functionality? It seems possible to move a PERSON via the UI, which is a much lighter operation for a mobile device.
We’re aware that moving a PLACE will also update all the records underneath it, as the entire parent hierarchy is stored within each record. Perhaps that’s an operation only an admin should initiate.
Let me preface this by mentioning that our households move frequently.
The challenges with using the cht-conf tool’s contact-move functionality are as follows:
It will be challenging to gather a list of affected items outside of the app that need to be moved, and in a timely fashion to ensure accuracy.
A person will need to be designated to execute this operation, requiring elevated permissions and/or access credentials to the database - which poses a security risk.
The move operation suggests that affected users clear their cache to properly reflect moved items, lest they risk working on stale items that fail to sync silently. Clearing the cache also poses a risk of potential data loss. While users can be trained to sync, they might not always do so consistently.
@diana is the expert here and might have more details, but here is what I know:
First, I just want to recognize that moving contacts in the CHT is a huge pain point and we recognize that. (See this forum thread for additional brainstorming around this issue). The main reason moving contacts is so tricky is because the contact has historically been the backbone of our syncing algorithm (determining which documents the server sends to an “offline” user and which docs the server will accept from an “offline” user). So, anytime you want to move a contact in a way that it should become visible to a new user and disappear from an existing user’s data, it gets tricky. Hence the note in the move contacts docs about users needing to clear their cache. (See this issue for discussion around the additional complexities related to moving users’s contacts.)
The ray of hope, though, is this issue where we are exploring the possibility of changing how users are connected to the contact hierarchy (thereby affecting how the CHT determines which docs to sync for the user). My hope is that the outcome of that issue (and probably additional followup projects) might make it much more feasible to move contacts around without having to worry about causing syncing issues with with users.
Now, getting down to more of the specifics of your question, it is important to note that each contact contains a complete record of who its parents (and all their ancestors) are in the hierarchy (again, this has historically been used by the syncing algorithm). Reports, on the other hand, just contain a record of which person/place they are associated with (without additional information about that person/place’s parents). So, moving a PERSON via an edit contact form is possible because it is simply editing that person doc’s parent data. This will automatically associate the person with the new parent place (*insert all the caveats about bad things happening if the move results in a user no longer having access to a person that they previously could see…).
However, moving a PLACE would require also updating all of the descendant contacts of the place (places/persons that exist below that place in the hierarchy). AFIK, there is not any logic in place in the CHT to do this kind of recursive update when editing a place. (Even adding logic like that would be sketchy at this point since an offline user might not even have access to all the descendant contacts (e.g. a supervisor with replication_depth configured so they can see CHW Areas, but not Households or patients…). Hence why the move-contacts action was implemented in cht-conf.
So, things are pretty bleak right now, but if we can decouple users syncing from the contact hierarchy then maybe we could avoid needing to de-normalize the entire ancestor hierarchy into each contact. This would get us to a place where moving PLACES would be much more feasible!