Re: [Gnumed-devel] GNUmed options / preferences and migration through successive updates

[Karsten Hilbert]

> I am noticing that among GNUmed's many client menus are a variety of  
> settings.
Doing it as menu items was the easiest.

> It is not always clear (to me) which of them are going to  
> affect
> 
> - all GNUmed users for that praxis
> - all GNUmed users by default unless they can override on a per-user  
> level
> - only that copy of the client
> - only that user (no matter which copy of the client they use)
Most apply to the current user in the current workplace only. None apply to the 
specific copy of
the client. We do not support that. Only per workplace.

> I think it would also make a challenge for anyone setting up GNUmed  
> to need to navigate into many individual menu items.
yes
 
> Would the following be useful to work toward:
> 
> 1) A single configuration area
yes, like in, say, firefox

> 2) Configuration is not managed "inside" a widget or plug-in or  
> arbitrary dialog but instead these locations can provide a button  
> which would pass a parameter to the configuration manager, taking the  
> user to the relevant area within the configuration manager
that would be how to actually do it in the code, no matter the interface, this 
is how it
is done even now

> 3) The configuration manager can have tabbed areas similar to how the  
> "Patient details" widget has "Identity" and "Contacts". Within the  
> manager, i could be the level of user privilege that determines what  
> is relevant to offer to be changed, and perhaps those areas that  
> require <gm-dbo> could be their own tab within the Manager.

maybe a radiobox at the top selecting "current user" vs "default all users"

then tabs as per config area below

> As far as migrating client preferences through successive updates, do  
> we expect any incompatibility if users (or their IT support) should  
> simply copy the "old" version of a user's .conf file into the new  
> client folder?
we do not really store anything beyond what is essentially needed at
startup before database connect in the config file(s) 

runtime options all live in the database and are fully upgraded with it

options may go stale and not be used anymore, no problem

if an option needs a change (say, datatype or changed content) it will be 
modified
within the database upgrade script (unless I forget)

> If some change is needed to the .conf file is it likely to be limited  
> to the addition of new "chunks" and would this enable any pieces  
> missing from the old .conf to be added-to (say from the /etc/gnumed/  
> file) upon first usage in the new client?
sure, as far as, say, profiles go, but those may need adjustment anyway to 
point to the
right database

I decided to again include the database *name* into the profile name such that 
people
can know which profile to select at startup time when there is several older 
ones.
This is a TODO item.

Karsten
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger