Hi all…
fixed the issue…with the help of kevin’s idea and Ken’s method. Basically Kevin’s thought gave me a blow to check it out…This is what I did
I have a History form made out of xmlformgen
the table name for the form is “form_history”
Real name of the form is “History Form”
Safe Name of the form is “history_form”
This is what was causing the trouble - the safe name and the table name mismatch.
So, I changed the safe name to “history” from “history_form”
I also went to phpmyadmin, and changed the registry table entries for the history form and other xmlformgen (in which I changed the safe name to match it up with table name)
Also changed the formdir name to the safe name in the forms table of the openemr database of the corresponding forms.
and this allowed for the E-sign to work perfectly.
NOW, NEED TO REMEMBER WHILE BUILDING XMLFORMGEN FORMS IS TO MATCH UP THE TABLE NAME WITH THE SAFE NAME AND EVERYTHING WILL BE FINE.
Hope, developers or others will find a suitable solution for this, till then this is the only choice and we need to keep it in mind while building forms.
Thank you everyone…and I can say that the issue is closed…
Just to make sure, in future the forms get the correct table name after being built from xmlformgen, changed the safe name of the xml codes for the forms in the contrib/forms/xmlformgen forlder. here is the commit, if possible please update into the codebase…
For the wiki, recommend placing it i wiki page for xmlformgen in red at the top and pertinent place to always use the proper format of name for safe name and table name. And I’d then link it to another section on that form for how to fix forms that were incorrectly made.
Ideally, we will come up with a fix for this, but agree with Ken on the other thread that there appears to be no straightforward way to grab this info from within the database. Do any of the developers know if below is possible:
Run function in report.php for a form (as is done in encounter screen), but throw the output away.
Figure out which sql table was first accessed during above run in report.php.
Do above 2 steps when the table doesn’t exist during the first try of the esign call.
Hi…Brady…the esign now works for these xmlformgen forms after the safe name changes. I tested it. I will place the solution in wiki…if I make any mistake in formatting in the wiki…please take care of it…
Good point. However, I think the report.php is a nice place to “anchor” the mapping of the table name for a form and fix this bug for all forms (new ones, legacy ones, and xmlgen ones) since it’s just a function so won’t break if include it. I envision the following steps to resolve the database in the function here ( openemr/Signable.php at master · openemr/openemr · GitHub ) would fix this bug:
Step 1:
Include report.php and see if a variable called $TABLE_NAME exists and that the table exists. If so, then use that. Would be easy to add this to the official forms and new forms.
if fail, then do Step 2:
Parse the report.php file for the first value of $table_name(it’s embedded in a function, so can’t get it via above include). If that table exists, then use that. This will capture the xmlformgen forms.
if fail, then do Step 3:
Do the method that now exists.
For the pain map form, this appears to be an unrelated bug. When one of those forms shows up in the encounter it breaks all the esign buttons with following javascript error:
$(…).esign is not a function
Is there any way to give e-sign ACL values? I was testing and found that even the nurse/front office can sign an encounter. Then its gone, no way to revoke even by the administrator or the physician.
If e-sign be given ACL values, like nurse can sign or a front office can sign but the administrator or the physician can open and add forms to the encounter, but cant make changes to the values or form signed by the front office or the nurse.
Could just have a function (like form_resolve_table($formdir) in library/api.inc that returns the table name and just then call this function to populate the table name when construct the esign class; then it can also be used for other places using forms and needing this information). And could do following in that function to resolve the table name(based on your suggestions):
Step 1. Grab it from a variable in table_info.php script
If step 1 fails, then Step 2. Use the current method (assuming form_formdir) and see if the table exists.
If step 2 fails, then Step 3. Parse the report.php file for the first value of $table_name(it’s embedded in a function, so can’t get it via above include). If that table exists, then use that. (this is important to support xmlformgen forms)
If all 3 steps above fail, then die and send an error to the log. The user can then fix it by adding a table_info.php file to the form.
If agree, then will post it on the Active projects page and see if can get somebody to work on it.
(btw, I am unclear on “data to hash for a given form”. a quick example will likely help me)