[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed options / preferences and migration through su
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] GNUmed options / preferences and migration through successive updates |
Date: |
Tue, 23 Sep 2008 02:00:51 +0200 |
> 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