[Gnumed-devel] 0.5.rc4 and GNUmed > Users …

[Jim Busser]

Improvements needed for 0.6

=================

        Users > Add user

In the short term, this should use the new (instead of old) person  
creation widget.

In the longer term, the menu should prompt the user to identify the  
person who is to be added (enlisted), and – for the situation where  
that person does not yet exist – we should provide a button to create  
the needed person (sparing disruption to user workflow).

=================

        Patient > Enlist as staff

1) This should be "Enlist as user"

2) Resulting dialog (window) titlebar (screenshot) should be changed  
from

        Enlist current patient as staff member

to

        Enlist as user

3) Label inside window should be

        About to add (enlist) as user:

4) Below the person summary, in place of "To enlist this person…" can  
we instead say simply:

        User parameters:

and
- make the labels red (as mandatory)
- make "Short alias" into "Alias (2-4 chars):"
- in view of GNUmed elsewhere using the label and dialog "Database"  
in reference to the the gm-dbo password can we alter "Database  
account" and "Database password" into
        User account
        User password
        User password, again

5) I deactivated Christine Chapel and when I tried to re-enlist her  
(assuming hers would be [chch]) the dialog only told me that
        "The database account [chch] is already listed
        as a staff member. There can be only one staff
        member for each database account."
so the logic would preferably first identify whether this person  
*already has* a user account and its status (active, inactive) and in  
this way disambiguate whether this is the source of the collision or  
whether it is because (e.g.) it is proposed to enlist
        Christopher Church
who may need
        [crch]

6) In a multi-user GNUmed as I hope to soon begin, we will need role  
support. The capacity to select from pre-defined (existing) roles  
needs to be added to the GUI. As soon as circumstances permit, can we  
start a thread on this? Items of discussion could also include an  
optional expiry date so that a short term worker can be pre- 
configured with an end date. Upon enabling this we would wish this  
tied to the login screen in which I would suggest that the "check"  
include a warning to the user when < 30 days of access remains. This  
could be made shorter if there would be no risk that the admins would  
be away and intermittent user(s) locked out. It risks being an  
annoyance for short term users but if they are only logging in a  
couple of times a day the warning may be tolerable for what will  
usually be less than the 20 working days on which the warnings would  
be encountered.

=================

        Users > Edit user

by default lists currently-active accounts, but deactivated users  
cannot be reactivated in this widget because they cannot be brought  
into focus (even via Person > Enlist).

Maybe the Edit user pane should list ALL users (including  
deactivated) with the activation status as a column.

Maybe the fields provided below the list should serve as a filter,  
instead of as an editing area, and should include the capacity to  
filter on activation status and level of user permissions (are we  
calling these "roles"?). Editing would then need to be implemented  
via double-click on a row,

The above would provide the ability to bring an inactive user into  
focus and make it possible for the Activate button to work.

Suggest these fields also include a "Role" field, so that it can be  
easily reviewed who has any of particular roles. Will our model allow  
more than one role per user? Also, provision for space for an  
expiration field.

Enlist as user.png
Description: application/applefile