# Moving of places

**URL:** <https://forum.communityhealthtoolkit.org/t/moving-of-places/3440>\
**Category:** Development\
**Tags:** forms, configuration, cht-conf\
**Created:** [April 11, 2024, 11:13am UTC](https://forum.communityhealthtoolkit.org/t/moving-of-places/3440 "2024-04-11T11:13:25Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\
**Post date:** [April 11, 2024, 4:34pm UTC](https://forum.communityhealthtoolkit.org/t/moving-of-places/3440/2 "2024-04-11T16:34:46Z")

</div>

@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](https://forum.communityhealthtoolkit.org/t/decreasing-the-number-of-reports-modified-by-a-big-move-contact-operation/2522/2) 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](https://docs.communityhealthtoolkit.org/apps/guides/updates/moving-contacts/) about users needing to clear their cache. (See [this issue](https://github.com/medic/cht-core/issues/8860) for discussion around the additional complexities related to moving _users’s contacts_.)

The ray of hope, though, is [this issue](https://github.com/medic/cht-core/issues/6543) 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!

---

_[View the full topic](https://forum.communityhealthtoolkit.org/t/moving-of-places/3440)._