Syan, thanks for both putting effort into this and for following the "mapped out" "official" wxg generation path.
A few comments: 1) conceptual For now what you wrote will do. Eventually we should enhance the "create patient" wizard to allow creating staff members. There would be an option to invoke it in such a way that the staff related wizard pages are displayed or not. Also pages would be pre-settable with the data of an existing patient if that patient/person were to become a staff member. A split of functionality seems in order: - editing an *existing* staff member would be done from a plugin which only "admin users" would want to include in their load list - creating a *new* staff member (possibly new person, too) would be done by an on-demand wizard (see above) invoked from either of a menu option and a button on the staff *editing* plugin This separation of concerns should surely reduce the number of cases to think of in each code path and thusly reduce the number of branches in the code. Boring code is good. 2) practical The admin_login stuff should be much simplified: The admin will always want to log into the same database, server, and port the original user is in. We will have to enhance gmPG.py to provide that information on request. But we should do those enhancements anyways since we have a "system information" screen on our roadmap. Thus the admin-login should reduce to account (preset to "gm-dbo") and password. I am more than willing to work with you on that. The pg_user group association should be made simpler for now: disable all groups but gm-doctors and make that one mandatory for now. I will have to explore what you checked in to make further sensible comments on how, perhaps, the workflow could be made more "generic". Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
