gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] permsssions needed for gmClinicalRecord to work


From: syan tan
Subject: [Gnumed-devel] permsssions needed for gmClinicalRecord to work
Date: Fri, 24 Oct 2003 11:26:21 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313

after loading with the public conf , there is no clinical update permissions, and the ones seen in the permission dump were done manually. So far, I've manually enabled audit__xxxx tables and sequences,
clin_root clin_encounter clin_episode_xxxx    tables and seq.
 I tried gmdbowner that didn't work either.
I think it would be easier for (potential) contributors to have permissions optionally off. BTW, I've put a test-client-c in testarea which is a copy of the latest client directory, but with most of the editareas filled using r. terrys' recent specs as a guide. It should run as gnumed.py. I've tried to keep the original editarea organization - using editarea subclasses, and the self.input_field map as a map to the widgets, I haven't overridden any of the handler functions ( _init_fields, and save_fields ) ; I did however add a delete button to the default button set ( easier to do first ; than right click list, then select
delete item from popup menu.  )
I know some people won't like it and may even bother to re-write it all, but it's just the layout according to editarea docs. To implement more than one field per line, I added a addColumn filter on the original widget lines list object concept, which changes the list by extracting each line element and wrapping extra elements and the original in a horizontal box sizer and making the sizer the new element for the list. New elements which are 'None' leave the original list item as is. Weighting is either default or through a weight map which gives the desired widths on a line if the first element on a line is supposed to be smaller.
New elements are added into the self.input_fields map as well.
At the moment, the current problem is that the all the unvalidated values of the widgets can be returned via a map. gmClinicalRecord and gmTmpPatient seem to be the preferred places for validation and database access logic. Most of the problems at the moment is that gmPG with its dumb "run_query returns false if error , makes things easier for the programmer " idea won't tell me what exception the driver's were throwing, so I had to modify it to print out a traceback (the log files weren't telling me, for some reason), and most of the errors so
far are "permission denied."
I'll keep an eye out for gmClinicalRecord updates from the business object developers , and maybe I'll be able to work out how to translate the widget map values as parameters for the right methods on it , ( just as soon as I stop getting permission denied errors). Will someone else write the gmClinicalRecord methods to translate the widget map values , or can I do some ? I can give a copy of the map key-values being returned as a document if anyone wants that. Or do you want the map values to have some validation /or re-organization on the editarea side? Comments please, ( or preferably, specification about just exactly how it wants to be done; I'm adopting the role of grunt programmer,
so you'd better make use of it) -  comments  if this is the way to go.
Or if anyone thinks what I'm doing now is a waste of time ( because they want to do it another way, (
but I think I am doing it  someone else's way )  ), please let me know.









reply via email to

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