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

[Karsten Hilbert]

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

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

> 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
expect it.

> 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
computable somehow.

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

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

gm-exc-handler-confirm-include-log.png
Description: PNG image