@gareth how can one limit the editing of peer persons (at the same hierarchy level) using the access restriction?
The only way I would see is to set the replication depth to 0 for this particular user role to 0.
But then, the user cannot see his own person and as a consequence, cannot start app forms, because they are tied to a person and not a user.
The person information then cannot be loaded into the form and one gets an error.
How can I use the replication depth to prevent users editing persons at the same hierarchy level?
Is it possible to include an additional level in the hierarchy to contain just the documents that the CHW should be able to access? Essentially this would mean each CHW would have their own “CHW Area” with all their households allocated to their area.
Dear @gareth,
This might work, but I won’t go for it, it does not look clean as an approach because that special, personal CHW area has no meaning for the field. Yet, it would be in the hierarchy and the data structure, each time a report is submitted. If we decided to use this kind of workarounds, we would end up in quite some chaos.
I’d rather suggest that this is properly dealt with at the permission level. I suggest an exception for it’s own contact.
It is quite unnatural that a CHW can see personal information of his peers.
The same goes for someone not being able to read his own personal information.
I agree that using a “personal CHW area” is not a clean solution, because it’s using the hierarchy for both a geographical area as well as a permissions structure. However the pattern is being used in many deployments currently and so far hasn’t ended up in chaos!
In the medium term there’s an outstanding issue to separate the two concepts which would solve your problem in a clean way.
