[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Workflow of and risks of including (or not including)
Re: [Gnumed-devel] Workflow of and risks of including (or not including) a log file with error handler exceptions
Fri, 09 May 2008 09:54:47 -0700
On 9-May-08, at 8:48 AM, Karsten Hilbert wrote:
That's why there are the options to:
- not include the log file
- control the receiver address
- annotate the log file with a comment
- save away a copy of the log file for later processing
True however these are all *manual* (operator-dependent) choices and
so we should take reasonable measures to avoid human error.
A reasonable measure would protect the clinical user who had
downloaded a copy of the client and who, having selected any database
other than the test server at salaam, risks clicking a button too
I can easily picture whoever would do the setup for a production
environment to do the configuration for a clinical workplace however
if they forget to designate an alternate email address there will be
a problem. If every new version of gnumed will require its client
configuration to be replaced or updated then we multiply the
opportunity for the problem to happen.
This is a point on which I feel it necessary to be aggressive.
We require at *least* one of the following:
1. "set "include log" checkbox off by default. If, from a project
perspective, you wish more sophistication to more often automatically
receive logs triggered during connections to *salaam*, then by all
means modify the exception handler to handle that condition?
2. Maybe better would be to adjust the client so that if they had
chosen to connect anything other than salaam, the exception handler
would not pre-populate a public-shared email address. Can you imagine
if a patient's information got accidentally posted to a list archive?
Despite being list co-administrator I have neither write-access to
the archive nor ability so far to talk to a human being about any
This only becomes a concern once people are into production but I may
be soon. Is it really such a problem to move
help desk =
into each "profile"? The profile for salaam could include
help desk = GNUmed Development List <address@hidden>
and the profile for GNUmed database on this machine (Linux/Mac) could be
help desk = Your own IT support <needs configuration>
One extra benefit could be that the user who ran into trouble and
wondered if this came from their local database could, without having
to change their configuration file, choose to try to connect to
salaam. Under the present design, if that connection also triggered
an error, the user could not easily email to gnumed-devel because
that would have been overwritten in the config file.
The only precaution would be to ask, when a user would exit a local
gnumed database and instead connect to salaam, would a new log file
be initiated, protecting what would have been in the previous log file?