That’s perfectly fine. It’s an edge case of an edge case (it’s hard for me to imagine why someone would be “removing a child” from a parent instead of voiding it anyway).
@Burke I think that’s an edge case and I think it’s really about semantics depending on the usecase, for instance in the case of humans if my parent disowns me, it doesn’t make me a child of their parent but it can be true in some situations but I can’t think of a good example.
So in summary, no need to handle the edge case exactly as Burke mentioned.
Stepping back, can we mark this removeObsGroupMember as deprecated, or is there some actual use case for it?
-Darius (by phone)
@darius are you implying that one should never have to remove a group member?
The implication is, obs groups are designed to represent the semantic relationship in multi-part observations (e.g., collecting not just the type of disease you had in the past, but date of onset and severity as well). Obs groups are not just an arbitrary hierarchy for unrelated observations. As such, “removing an observation from a group without voiding it” is strange.
For example, imagine we have an obs group to record patient answers about signs & symptoms:
Sign & Symptoms ├ Name ├ Onset date └ Severity
So, we collect some data:
Signs & Symptoms
├ Nausea
├ Yesterday
└ Moderately Severe
Deleting (voiding) the severity observation would make sense (i.e., the Moderately Severe answer was invalid); however, “removing” the severity response and then just saying that we have an observation of Moderately Severe as an independent observation in the encounter (no longer in the context of the obs group) is non-sensical.
@burke and others, what is the agreed way forward for this? https://issues.openmrs.org/browse/TRUNK-4956
I think immutability is really meant to be from the point of view of the API because clients are actually allowed to change fields on an Obs and the API is supposed to silently void and replace them, the interceptor was added to be a door man just in case something leaks through. One of my proposals on another thread was to actually change the error message in the immutable entity interceptor to something else that isn’t misleading.