Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need clarity regarding if having a person contact be the parent of other contacts is "supported" #9584

Open
jkuester opened this issue Oct 24, 2024 · 0 comments
Labels
Type: Improvement Make something better

Comments

@jkuester
Copy link
Contributor

What feature do you want to improve?
Currently, you can use the contact_types config and define a contact type with "person": true and then use that contact type in the parents array for another contact type. cht-conf will compile and upload this config with no errors.

Then, in the app, users will see the option to create new contacts as children of the person.

Everything seems to work fine. You just end up with person contacts that are not leafs in the contact hierarchy.

Describe the improvement you'd like
My main question is if this is desired behavior that we want to support? In a number of past conversations regarding the CHT data-model, the idea of person's as being leaf-contacts has been discussed and has been characterized as the way things "should" be (both conceptually and semantically). However, there does not seem to actually be anything that prevents you from configuring your instance to allow this and I am concerned that any incompatibilities might be subtle or confusing.

Describe alternatives you've considered
If we don't want to allow persons to be parents of other contacts, we should explicitly prevent having this configured (either in cht-core or in cht-conf). If we want to support this, we need to be sure this is properly socialized (maybe I am the only person confused about this... 😅 ) so that assumptions do not creep into our code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement Make something better
Projects
None yet
Development

No branches or pull requests

1 participant