[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-bugs] <bug>: on saving printing document in overview scr
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-bugs] <bug>: on saving printing document in overview scr |
Date: |
Wed, 5 Sep 2012 16:04:46 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hello Marc,
thanks for your report. I have seen a very similar report
by another user (which I have CCed) before.
Can we try to retrace the exact steps ?
> user comment : on saving printing document in overview screen
Do you mean that you were in the overview screen, then you
printed a document, GNUmed asked you which episode to save
it under, and then the bug came up ?
Let's see what the log gives us. First:
> 2012-09-05 08:33:04 ERROR gm.datetime
> (/usr/share/gnumed/Gnumed/pycommon/gmDateTime.py::pydt_strftime() #262):
> Python cannot strftime() this <datetime>
> Traceback (most recent call last):
> File "/usr/share/gnumed/Gnumed/pycommon/gmDateTime.py", line 260, in
> pydt_strftime
> return dt.strftime(format).decode(encoding, 'replace')
> ValueError: year=193 is before 1900; the datetime strftime() methods require
> year >= 1900
> 2012-09-05 08:33:26 CRITICAL gm.db
> (/usr/share/gnumed/Gnumed/pycommon/gmBusinessDBObject.py::refetch_payload()
> #504): [cIdentity:795]: cannot reload, payload changed
GNUmed seems to think that something is odd (likely the date
of birth) with Patient 795. That was most probably a typo
some time ago when entering the year.
Please try to correct this and see if you can evoke the bug
again - it may have been followup error (which would still
be a bug but that might give us hints).
Next, given this:
> 2012-09-05 08:33:45 ERROR gm.docs
> (/usr/share/gnumed/Gnumed/business/gmDocuments.py::update_data_from_file()
> #308): [/tmp/gnumed/gm-wefjPq/gm-L-Template-QRjPiF-instance.tex] is not a
> readable file
> 2012-09-05 08:33:45 ERROR gm.docs
> (/usr/share/gnumed/Gnumed/business/gmDocuments.py::add_part() #513): cannot
> import binary data from
> [/tmp/gnumed/gm-wefjPq/gm-L-Template-QRjPiF-instance.tex] into document part
> 2012-09-05 08:33:45 ERROR gm.docs
> (/usr/share/gnumed/Gnumed/business/gmDocuments.py::add_parts_from_files()
> #533): cannot instantiate document part object
and this:
> client version: 1.2.1
and this:
1.2.2 CHANGELOG
FIX: failure to save .tex bill files
and this:
gnumed-client-de:
Installiert: 1.2.3-1
Installationskandidat: 1.1.17-1
Paket-Pinning: 1.1.17-1
Versionstabelle:
*** 1.2.3-1 601
10 ftp://ftp.de.debian.org/debian/ experimental/main i386
Packages
100 /var/lib/dpkg/status
1.1.17-1 601
990 http://ftp.de.debian.org/debian/ wheezy/main i386 Packages
990 ftp://ftp.de.debian.org/debian/ testing/main i386 Packages
50 ftp://ftp.de.debian.org/debian/ unstable/main i386 Packages
0.7.10-3 601
500 http://ftp.de.debian.org/debian/ squeeze/main i386 Packages
I would like to ask you to upgrade to 1.2.3
apt-get install -t experimental gnumed-client-de
and try again whether you can reproduce the bug.
I don't, however, think we've gotten to the root of the
problem just yet. Next we find this:
> 2012-09-05 11:10:13 DEBUG gm.gui
> (/usr/share/gnumed/Gnumed/wxpython/gmExceptionHandlingWidgets.py::handle_uncaught_exception_wx()
> #186): unhandled exception caught:
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
> line 14665, in <lambda>
> lambda event: event.callable(*event.args, **event.kw) )
> File "/usr/share/gnumed/Gnumed/wxpython/gmEMRBrowser.py", line 266, in
> __update_text_for_selected_node
> with_co_encountlet_hints = True
> File "/usr/share/gnumed/Gnumed/business/gmEMRStructItems.py", line 1793, in
> format
> raise ValueError(msg)
> ValueError: <patient>.ID = 216 but encounter 2839 belongs to patient 744
Which tells us that GNUmed seems greatly confused at being
told to reconcile two different patients. So in the vain of
better being safe than sorry it throws up its hands in
despair. This now begs the question why.
*************************************************
Did you - by any chance - attempt to print a bill
NOT belonging to the active patient ?
*************************************************
Sheeesh, trying that it turns out GNUmed will do major BS
and create/link the PDF for/to the *ACTIVE* patient rather
than the one that's linked to the bill %-//
This still does not quite explain the exception you saw (at
least I cannot evoke one) but this needs fixing immediately.
I'm looking into the issue right now including developing an
SQL query pulling up the faulty invoices (which is gladly
possible by cross-checking
bill->fk_receiver_identity/bill_item->patient/document->patient
You assured us that you were printing while the (new,
patient) overview was active:
> user comment : on saving printing document in overview screen
However, the above code belongs to the EMR tree browser:
> File "/usr/share/gnumed/Gnumed/wxpython/gmEMRBrowser.py", line 266, in
> __update_text_for_selected_node
which should, however, only be run when the EMR tree plugin
is active.
Can you therefore describe the exact steps needed to
reproduce including what state the GUI was in at each step ?
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346