For the various levels of our places hierarchy (npo, team_area, indawo, household) a primary contact can be searched and selected.
What we’ve found is that the person items of a different top level place (npo), and the person’s in it’s child places, are available for selection throughout.
In our case, the top level places (npo), are totally independent from another - and the selections need to be restricted.
Eg:
NPO1 - has a team_area named TeamArea1 with a person named Steven.
NPO2 - has a team_area named TeamArea2 with 2 people named Bob and Steve respectively.
In the team_area-create - form TeamArea2 form we want to select Steve as our primary contact, but Steven from a different npo is also shown.
We’re making use of the select-contact type-typehere for filtering to a specific person type, which works great, and were wondering if we could somehow extend this filtering to satisfy our use case.
At this time, there’s no way of restricting the search to contacts that have a certain ancestor. The only way that this can be done is through restricting the data set by using offline users that would only replicate the contacts that you’re interested in.
This would be a great feature though. I think it kind of falls into the same category as this issue, do you think?
Thank you for the quick feedback and explanation.
If I understand this correctly the issue will be mitigated by the logged in user role.
They are linked to a specific place which is either the top level hierarchy item, or one if it’s children, and therefor will only see the related work and people.
Only the admin will have this overview - where the “issue” is present.
Though the challenge remains on the lowest level (household), where a CHW will have multiple household members per household assigned to them.
While trying to assign a household head (primary contact) the db lookup can return a few similarly named individuals - especially since, in our use case, a single CHW can have a total of about 500 members assigned.
To have an additional filter will make the returned list not only much shorter, but also address the risk of selecting a completely different household’s member.
Thank you for the Github issue link, it does seem like such a “restriction” could help address the requirement.
I’ll leave a short comment and eagerly await the implementation .
.