[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
Sun, 11 May 2008 00:17:16 +0200
On Fri, May 09, 2008 at 09:54:47AM -0700, James Busser wrote:
>> That's why there are the options to:
> 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.
Agree. Make that "any server not explicitely marked for
default inclusion of log file by an administrator".
> 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?
It cannot easily since it is well-decoupled from such
> 2. Maybe better would be to adjust the client so that if they had chosen
> to connect anything other than salaam,
Which value ("salaam") is bound to change when we least
> the exception handler would not
> pre-populate a public-shared email address
Whatever that may be. It seems hard for human users to know
what a particular email might mean let alone it being
> Can you imagine if a
> patient's information got accidentally posted to a list archive?
That is certainly something we should like to avoid.
> 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"?
Hold it, hold it. I never said we won't. I simply take
cautious steps as usual.
The code now does this:
- profiles can be annotated with "by default include log in bug report"
- only salaam will be pre-annotated with that flag
- if False or missing
- checkbox to include will be off
- if overriden by user to indeed include log confirmation is
requested (see screenshot)
- if True
- checkbox defaults to on
- can still be changed to off
- however, if on, no confirmation will be requested
Indeed, setting a help desk per profile seems useful, too.
Will include that, too.
> 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?
Well, unless overriden by --log-file= the file name contains
the process ID of the corresponding GNUmed client process.
This will eventually reoccur but fairly rarely. Whenever an
unanticipated exception occurs, however, a copy of the
current log is made to ~/gnumed/logs/ and the file name
contains the current date/time which is even more unlikely
to occur again. And beyond that the user can always request
an explicit copy under an arbitrary name.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Description: PNG image