gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] rename Help > Debugging > Lock/unlock patient


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] rename Help > Debugging > Lock/unlock patient
Date: Sat, 6 Aug 2011 15:56:27 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

This is a debugging function and should not be abused to
become a feature since that may effect streams of desires.

The client code locks the patient when, say, an external
software is run which both returns patient related data and
runs concurrently rather than blocking.

Also, the scripting engine can lock the client onto a
patient which is useful when the client is driven by other
software so that users typing into a random client cannot
switch to another patient while outside software expects to
work with one it activated.

> The current name makes it sound like the user might (by applying a lock) make 
> the patient read-only.

I agree we can improve the naming of the menu item.

> I notice it is even possible to lock (prevent searching) at instantiation, 
> when there is not yet any patient in focus and the search text says
> 
>       <type here to search patient>
> 
> however
> 
> 1) is it possible to cause this also to have appended
> 
>       (locked)

The lock state is tracked by the gmPerson.py::gmCurrentPatient()
class (such that, no matter the access, lock is lock).

The patient search field will now display:

        <patient search locked>'

if locked and no patient is active.

> 3) can we rename it
>
>       Lock/unlock patient search

Done. Note, also, how the menu item explanation already says:

        Lock/unlock patient - USE ONLY IF YOU KNOW WHAT YOU ARE DOING !

(now: Lock/unlock patient search - USE ONLY IF YOU KNOW WHAT YOU ARE DOING !)

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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