Openemr 2.9.0 bug

gutiersa wrote on Saturday, August 09, 2008:

consider having a bug reporting forum.

I have upgraded my system to 2.9.0 on 8-7-2008 and are using it in my practice. I hope to post a longer thread with our experience. This problem i’m not sure I can fix hence I post here. Here is our problem:

When the front desk personnel is calling patients to confirm appts, they open that particular appt, but the new window has todays date on it, not the actual appt date. When they save (to enter the fact that the pt has been reminded) the appt gets moved to today’s date. To avoid this they must actively remember to re select the date of the appt. before saving. Most of the times they forget.

I would like the appt window to remember the appt. date. How can I change this??

thanks

sunsetsystems wrote on Monday, August 11, 2008:

Looks like this bug was introduced in revision 1.40 of interface/main/calendar/add_edit_event.php on 2008-05-02, entitled "fully handles repeating event edits and deletes now".  This revision appears to be a big change to the logic.

Here’s a suggested fix.  Change line 775 of this script from:

  //$date = $row[‘pc_eventDate’];

to:

  if (empty($_GET[‘date’])) $date = $row[‘pc_eventDate’];

Could the author of this revision please check the related code and indicate if this fix is OK, and if anything else needs correction?

Rod
www.sunsetsystems.com

gutiersa wrote on Monday, August 11, 2008:

thanks,

incidentally you also can no longer change the provider of the particular appt. if the wrong provider is chosen. The apt must be deleted and a new appt created.

cfapress wrote on Wednesday, August 13, 2008:

I’ll take a look at the code today (Aug 13th) and make the necessary fixes.

Jason

cfapress wrote on Wednesday, August 13, 2008:

AH! I see the trouble. The calendar view templates were not uniformly updated. When I created the new Outlook style calendars I did not reflect the changes in the old default and fancy styles as I should have. The code in those older templates should be corrected to pass a GET variable named ‘date’. Once that is done the bug in the ‘add_edit_event’ code will magically go away.

As for the inability to change the provider once an event has been created, this was in place since version 1.26 of the source file. The comment on that CVS entry is:
"Optional new calendar layout, and restriction of each user to one facility, from Nethanel Vilensky (see Changelog)"

It sounds like the restriction was added when multiple facilities were enacted. I can’t speak to the reasoning behind the change myself but I don’t see a good reason why to keep it this way. The original select box was a good solution.

For the time being I’ll leave the provider select box alone. However I will go into the calendar templates and update them to fix the bug related to the ‘current date’ in existing recurring events.

Jason

sunsetsystems wrote on Wednesday, August 13, 2008:

Thanks Jason.  I did already check in the workaround that I mentioned above, but that should be harmless when the date is passed in as a GET parameter.

I agree that the provider should be changeable.  I don’t mind if you want to undo that restriction.

Rod
www.sunsetsystems.com

cfapress wrote on Thursday, August 14, 2008:

Rod,

I’ll make the changes to the code tomorrow and check them into CVS. Part of the changes to make will include removing the lock on the Provider select box.

Jason

cfapress wrote on Thursday, August 14, 2008:

Patches have been made and committed to CVS. The two bugs described in this message thread have been corrected.

Jason

gutiersa wrote on Friday, August 15, 2008:

thanks so much!