Need clarity regarding if having a person
contact be the parent of other contacts is "supported"
#9584
Labels
Type: Improvement
Make something better
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 theparents
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
person
s 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.The text was updated successfully, but these errors were encountered: