[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-bugs] Bug when leaving a patient (edit encounter details) de
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-bugs] Bug when leaving a patient (edit encounter details) default value for encounter Type |
Date: |
Mon, 21 Nov 2011 15:44:19 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Fri, Nov 18, 2011 at 04:04:46AM +0000, Jim Busser wrote:
> Even despite that an encounter type had been changed from
> the default, and saved (together with a progress note), when
> it is attempted to change to a different patient, the editor
> window does not pick up the changed value and seems to offer
> instead the default.
>
> On account of it being a production patient, I rejected
> the "Save" and after switching patients, went back to the
> original patient and confirmed that the originally-saved
> value had been preserved.
This is now fixed for 1.1.4. The issue was rather deeply
hidden. Here's the commit message:
Fix failure to properly propagate changes to the current encounter
There's a design problem with the business object base
class: the class purports that the last
_cmds_store_payload need only appropriately return XMIN
because all other field changes happen by explicit
setting from the user side of things. This, however,
only holds when the class sits atop a query which does
NOT include any calculated (say, _(column)) or
denormalized (say both fk_type and type) fields. In case
it does it will contain updated fields (say fk_type) but
also non-updated ones (say, the denormalized type behind
the fk_type) because storing the payload does not
automatically return those indirect fields. This design
gotcha only comes to fruition when class instances are
held for a significant amount of time beyond them being
called with .save() or .save_payload() which, in current
code, only ever happens with the current encounter
instance being held by the clinical record class
instance of a patient. That's where J.Busser noticed it.
It could easily happen with other objects as well, though,
given there usage pattern conforms to the above constraints.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346