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.)
To fix this, we should add “groupMembers” to the list of mutable fields listed on the ImmutableObsInterceptor. 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.
An argument could be made that the alternative is the more "correct" approach, but we will go with making groupMembers mutable because it also maintains existing functionality.
Related Talk post: