[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Workflow of and risks of including (or not including)

From: James Busser
Subject: Re: [Gnumed-devel] Workflow of and risks of including (or not including) a log file with error handler exceptions
Date: 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 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?

reply via email to

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