gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] (no subject)


From: Syan Tan
Subject: [Gnumed-devel] (no subject)
Date: Tue, 17 Jan 2006 15:20:33 +0800





On Tue Jan 17 13:14 , address@hidden sent:

    Quoting Syan Tan <address@hidden>:

    > working on the appointments use case, I 've come across the utility use 
case
    > of creatingnew pg_users via the gui ; basically user name , password, 
confirm
    > password, checkbox whichgroups the user should belong in , then update
    > button, then a small admin login modal dialog,( which has host,port ,
    > database, user, password, with has defaults for the first 3)
    why re-write this? why not use the existing one?

the initial user for the appointments was an office user. But later I found
one needed to be admin , in case a newly created staff needed to be associated 
with
a pg_user not yet created. I'm also using gnome desktop, which seems to do 
things
this way ( e.g. request admin access when needed, e.g. when committing synaptic
or aptitude
package selections, when reactivating a lan connection in the Network Connection
manager).

Alternatively , only allow the admin to use the create staff gui, who also has 
the connection privilege to make pg_users. However, entering session_plans for 
staff 
seems to be an office duty, as people might want to make an adhoc change for 
next
week etc..
It seemed a little awkward to login twice , in order to say, create the
session_plans 
for newly arrived staff , who also need to be entered. 
...  But as you say , this use case is infrequent enough that maybe it is just
better to have to login twice.

    , and then
    > attempt to get an ordinary dbapi connection object , then statements to
    > insert or updatethe pg_users.
    where are the statements? in a separate module?

    > also checks to see if admin user has createuser
    > boolean attribute set, and if not,requests the user to negotiate that or 
do
    > it elsewhere via a terminal postgres user session.The reason for being 
able
    > to create pg_users via the gui is to be able to associate it withnew staff
    > being entered, as the appointments is useful for organizing when more than
    > one staff.Is this acceptable , ( say just for the AU localization , 
initially
    We do need this functionality, it's good that you've done this.
    but it seems you're avoiding linking to the
    existing python code for no reason (there may be a good reason that I can't
    see)

    Can you post the code to the list, then we can assess.

no worries.

    Also, how does this relate to your subject line?

    Ian
can't remember.

Attachment: gmAU_AppointV01.py
Description: Binary data

Attachment: gmAU_AppointV01Plugin.py
Description: Binary data

Attachment: gmAU_DBUserSetup.py
Description: Binary data

Attachment: appoint2.sql
Description: Binary data


reply via email to

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