gnumed-bugs
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]