[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] GNUmed client > 0.2.8.1 menu alteration proposals
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] GNUmed client > 0.2.8.1 menu alteration proposals |
Date: |
Fri, 04 Jan 2008 08:48:37 -0800 |
On 4-Jan-08, at 4:00 AM, Karsten Hilbert wrote:
By design all options that get set explicitely are
constrained to "this" user and workplace. It is just that an
administrator can set user/workplace independant values
which will get looked up and then used as the default value
should no user/workplace specific default exist.
A related question, apart from how we group menu options, is how to
manage the availability of features depending on the user. For
example, doctors would be allowed to do and access things that
receptionists may not. And maybe it is desirable that not every
doctor be able to do all things administrative. What are the best (or
even manageable) choices among
- configuring the presence or absence of menu options, by user
- keeping the menu options constant across users, but just enabling
or disabling (dimming) menu items according to user
- keeping the same menu items available to all users, communicating
anything that is disallowed to the user e.g. with a beep and a notice
in the status line like
"Feature restricted ... insufficient privileges"
... likewise the question would arise for plug-ins, whether to
control whether certain users can add them to their plug-in lists and
how these can or cannot be used once the user is back in the client
Naturally some menu items or plug-ins will permit some users partial
views or partial write-access, those would be controlled
programmatically inside the menu item or plug-in