Re: [Gnumed-devel] Workflow of and risks of including (or not including) a log file with error handler exceptions

[James Busser]

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  
quickly.

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  
list problems.

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?