Does anyone know what “preferred” is supposed to mean with respect to relationship types?
I’m currently working on finishing Initializer support for relationship types. The only documentation I’ve found that tries to explain what “preferred” means is this, which is not very helpful:
“Preferred” relationship types are those that should be shown as default types when adding/editing a person’s relationships
Okay, so what’s a “default” relationship type? When are the non-default types used?
Looks like the property was invented >13 years ago… so @burke @mseaton ? @darius @justin ?
EDIT: Actually, same question about “weight.” Is that used anywhere?
IIRC an early patient dashboard UI looked like:
* Community Health Worker: [widget to pick a person]
* Children: [widget to pick a person]
* Parent: [widget to pick a person]
* Other: [widget to pick a type and a person]
Preferred relationship types were explicitly listed out, and non-preferred required you to go through “other.”
(In retrospect this didn’t belong in the underlying data model, but in some implementation-specific UI configuration.)
Awesome, thanks @darius . Any idea about
And what’s the path forward for these elements? I assume we should leave them out of Iniz @mksd ? Should we deprecate them in core? @burke ?
I would assume
weight would be used to control the sort order of relationships.
If they aren’t going to be used going forward, we could deprecate them. If they are still used in 2.x implementations, then it might be worth letting iniz optionally support them (especially if there are implementations still using them).
I would tend to agree, especially because it’s relatively costless for Iniz to do so. And I think their optional support is already part of @bistenes’s PR.
Furthermore Iniz is in general pretty agnostic to the functional meaning of the entities it supports. It dumbly looks at what the available members are and attempts to provide support for all of them.
I actually left a comment on the PR here, I would be curious to know what people on this thread think.
@bistenes I don’t want this to drag your work, so if people don’t react, I’m happy to merge it as it is.