sunsetsystems wrote on Friday, April 08, 2011:
Got an error in sql/4_0_0-to-4_1_0_upgrade.sql that causes upgrades to fail. This line:
INSERT INTO form_encounter(billing_facility) SELECT id FROM facility ORDER BY billing_location DESC, id ASC LIMIT 1
I think you mean to update the existing rows, not add a new one. Also the ending semicolon is missing.
zhhealthcare wrote on Friday, April 08, 2011:
The sql upgrade error is corrected.
Updated in git to the branch
(calendar_comments) accessible at
https://github.com/zhhealthcare/openemr/commits/calendar_comments
The patch file is also uploaded at
https://sourceforge.net/tracker/?func=detail&atid=1245239&aid=3086688&group_id=6
0081
with name ‘0002-sql-upgrade-error-is-corrected.patch’
Thanks
Paul
bradymiller wrote on Friday, April 08, 2011:
hi,
Committed both of your above fixes. I am assuming you tested the upgrade script with these changes. For all developers, please ensure you test the upgrade scripts. Best way is to test them on an upgrade and then run it again to ensure your ‘If’ statements are working correctly.
thanks,
-brady
zhhealthcare wrote on Tuesday, April 12, 2011:
Billing Facility was not getting selected in the Add/Edit event screen of calendar.
It is corrected.
Updated in git to the branch
(calendar_comments) accessible at
https://github.com/zhhealthcare/openemr/commits/calendar_comments
The patch file is also uploaded at
https://sourceforge.net/tracker/?func=detail&atid=1245239&aid=3086688&group_id=60081
with name ‘0001-Billing-Facility-is-not-getting-selected.patch’
Thanks
Paul
bradymiller wrote on Tuesday, April 12, 2011:
hi,
Just committed your fix to sourceforge.
thanks,
-brady
zhhealthcare wrote on Tuesday, April 12, 2011:
One more bug fix,billing facility not getting selected in New encounter form.
It is corrected.
Updated in git to the branch
(calendar_comments) accessible at
https://github.com/zhhealthcare/openemr/commits/calendar_comments
The patch file is also uploaded at
https://sourceforge.net/tracker/?func=detail&atid=1245239&aid=3086688&group_id=60081
with name ‘0001-one-more-bug-fix-billing-facility-not-getting-select.patch’
Thanks
Paul
bradymiller wrote on Tuesday, April 12, 2011:
hi,
Just committed your additional bug fix to sourceforge.
thanks,
-brady
zhhealthcare wrote on Tuesday, April 19, 2011:
Issue that payer name not listing in the x12 is resolved.
Updated in git to the branch
(calendar_comments) accessible at
https://github.com/zhhealthcare/openemr/commits/calendar_comments
The patch file is also uploaded at
https://sourceforge.net/tracker/?func=detail&atid=1245239&aid=3086688&group_id=60081
with name ‘0001-Issue-that-payer-name-not-listing-in-the-x12.patch’
Thanks
Paul
bradymiller wrote on Wednesday, April 20, 2011:
Hi,
I just committed your fix to sourceforge.
thanks,
-brady
aethelwulffe wrote on Wednesday, May 04, 2011:
I have a big WTF….
I downloaded the calender_comments branch, set it up with my database (sql_upgrade from 4.0). I then (hoping to put this mod into real service) attempted to pop in my valueoptions x12 mod. Today’s developer machine is xp Pro and xammp pack from the 3.2 release
I reviewed and merged my X12Partner.class.php, Claim.class.php, and gen_x12_837.inc.php. fine and dandy (I think). I just replaced templates\x12_partners\general_edit.html with my own after reviewing for changes I might need (none apparent).
I fired up XAMMP, logged on(version 4.1.0 DEV now), and low and behold, the frame for add/view an x12 partner configuration was EXACTLY like the original, with all the out-of-order and missing EDI header info. I cleaned out the cache, logged on with a different machine, checked/double/tripple-re-created the whole dang thing…still the same, no new layout. I took out the file, and yep…empty white frame. Popped it back in, and there it was…but still the original! The new looks NOTHING like the old, in our out of the browser, but the darn machine still knows what the original looked like.
I tried modifying the general_edit.html file in-situ. All I did was delete a space out of a bit of text output. Fired up the EMR, Squat! Nothing there. If I put the original or my modified file, it works, but only showing the original display. If I modify either file in any way, it breaks some code somewhere.
It is now 6:14 AM. I have been screwing with this for ten hours. Would someone Puh-leez come and (in order of preference) A. Shoot me dead before I hurt myself. Or B. Tell me how the heck I can have “ghost code”. What combination of controller, checksum watchdog, compiler or whatever is bagging me here?
….to conserve bandwidth I shall refrain from posting the animated gif of the guy beating himself to death on the keyboard.
cassilup wrote on Wednesday, May 04, 2011:
Did you try clearing the Smarty Cache?
(/interface/main/calendar/modules/PostCalendar/pntemplates directory)
cassilup wrote on Wednesday, May 04, 2011:
sorry, I was thinking about the ‘compiled’ directory:
/interface/main/calendar/modules/PostCalendar/pntemplates/<b>compiled</b>
Clear everything in there. See if it works.
aethelwulffe wrote on Wednesday, May 04, 2011:
Dude!
I >just< decided that there must be something compiling the template somewhere to get this kind of behavior. I found the smarty compiler code and decided to look on the forum for more info…and there you were. Thanks man!
aethelwulffe wrote on Wednesday, May 04, 2011:
Cleared it out…no joy. Now the code is broke…at least with my version of the template in there. Worked fine before, but…
Anywho, I cleared the cache as well (don’t know what all that does yet). Checked the current compiles…no general edit. Maybe my version won’t compile with the html header it has. If this is all there is to it, I bet I can get it now, I just have to work on other things, sleep, then get to it. :) Thanks for the redirect to reality!
cassilup wrote on Wednesday, May 04, 2011:
Sure thing!
Well - it worked before you cleared the compiled folder because you had a working version that had already been compiled.
You modified something in the .html file, saved and saw no change… Cleared the folder and it served you the white screen of death.
add
ini_set('display_errors', 1);
error_reporting(E_ALL);
at the beginning of your .html file, clear the compiled folder and reload. You should see where the glitch is.
zhhealthcare wrote on Wednesday, May 04, 2011:
if the pntemplate folder have write permission. if not when trying to compile it will not work
aethelwulffe wrote on Wednesday, May 04, 2011:
Actually, I cleared out the directory, and it produced three compiles for “list” but none for a “general_edit”.
Hmm…SOme careful science and T/S after some sleep. Almost done with work.
Known effects: It would match up a compiled version to a file from my 4.0 install(modified), or from the branch, but only show what I assume was a default or initially compiled version (not on the same machine to check right now) that seemed to be compatible (date difference?) so permissions may come into play.
Permissions are harder to check on XP vs Server=another reason to leave this til tomorrow for me.
In one test version I DID run the setup script for funsies. It reported a list of directories that had permissions set properly. I don’t remember seeing these directories in there one way or another.
I wish I would have carefully checked what was in that batch of compiles before I tossed it.
I’ll enable logging and some debugs. We shall find out who the culprit is…Muahahahahahahahah!
aethelwulffe wrote on Friday, May 06, 2011:
OK, I got it.
…sorry for hijacking your thread Paul. A rather lot of stuff actually changed with this version, and my general_edit.html was too HTML-ish for smarty to compile. I had to carefully use the exact same conventions that the base file used, and just edit it as a new document. Works great now. I don’t know what changed between the two versions that suddenly made it not compile, but I now know I can’t use line breaks, capital letters (like <TD> instead of <td>) and a number of other things. I re-formatted and removed HTML headers without actually running debug scripts, and it worked. -good enough for me.
aethelwulffe wrote on Friday, May 06, 2011:
Otay…
1. Encounter Visit category is not selected properly to match calender entry. (facility and billing facility are though)
2. Repeat appointments (two test appointments, 6th month, repeat until 2013, one with a status of just 30 minutes, and one as an all day 24 hour event) show up in the patient summary up to three times with the same date in each (though the appointments are there).
anonymous wrote on Thursday, May 12, 2011:
Hi folks,
Thanks much for the Calendar improvements, really. I have an OT question, or more like a hope for a little guidance from PostCalendar savvy folks.
I posted a seperate thread at https://sourceforge.net/projects/openemr/forums/forum/202506/topic/4528042
Essentially I’m adding room selection to scheduling, but it’s just a short term solution. Eventually I might like to put together a more robust system with the intention of submitting it, but right now this is just for one implementation.