|
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.
gmAU_AppointV01.py
Description: Binary data
gmAU_AppointV01Plugin.py
Description: Binary data
gmAU_DBUserSetup.py
Description: Binary data
appoint2.sql
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |