We recently upgraded from 2.3.x and 2.5.x and discovered that, at least when working RESTfully, we are no longer able to update an obs group by adding another obs to it.
Concretely, if I construct a REST call to the Encounter endpoint to update an existing Encounter, and within the Encounter I attempt to add a Obs to an existing Obs Group, it fails, because Hibermate throws an exception saying that “groupMembers” is immutable.
In a way, this makes sense, because the ImmutableObsInterceptor is designed to prevent Obs from being changed, and the “groupMembers” is not one of the fields marked as mutable.
It’s unclear why this worked in 2.3.x and does not work in 2.5.x. My guess is that it’s got something to do with the fact that groupMembers is not a direct property on Obs, but an inverse property, since groupMembers are defined via obs_group_id on the child obs.
(In fact, we haven’t noticed this problem when saving Obs Groups via HTML Form Entry, and I suspect this is because HTML Form Entry just saves the new child obs, and so the parent Obs is never “touched”, although the association is made.)
Thoughts on how to fix this? For me, the easiest thing to do would be to just add “groupMembers” to the list of mutable fields listed on the ImmutableObsInterceptor. I quickly tested and this does fix the problem. An argument could be made that this the correct behavior, because when adding a child obs to a group you are not modifying any existing rows in the database, just adding a new row. The alternative would be to, behind the scenes, void all the existing obs rows in the group in the database, recreate new obs for those rows (without any changes) and then create the row for the new obs. But this seems pointless because you’d be voiding obs and generating more rows in the database without actually gaining any additional audit information (you can already tell that the new obs was added to the group at a later date because it’s date_created would be after that of the parent and the initial child obs).
As I write this out I’m becoming more convinced that simply adding “groupMembers” to the list of mutable fields is the best solution (though I’m certainly biased because it’s the easiest by far…
)
Thoughts? @dkayiwa @ibacher @burke @mseaton \
Take care, Mark