when entering appointments from calendar view, if you are in day view the timeslots are not clickable, i.e. you can’t click on the time & it opens up an event entry window. If you back out to the week view, then the timeslots turn back into hyperlinks & work the way they are supposed to.
Is this a bug or is it that way by design for some reason?
I also noticed that if you change the “category” of a scheduled appointment that is for the next day or greater, it puts the current day’s date as the appointment date.
[Note: We had made the following category additions: "F/U" and "Re-scheduled" when we first went live with OpenEMR]
For example, today (9/3) a patient called to re-schedule their "F/U" appointment that was to take place on 9/4. The category for the patient was changed from "F/U" to "Re-scheduled." It was discovered later that the "Re-scheduled" appointment was now on 9/3 when in fact the appointment had been for 9/4.
We are using the traditional/original calendar ( pink & blue).
As to the issue about category changes affecting the appointment date…
I’m not sure. Can you clarify the exact steps you take to have this error appear?
In the original calendar layout (pink/blue) I do the following:
1.) Today’s date is 09-08-2008. I go into the calendar and click on the appointment time for a patient scheduled for tomorrow ( 09-09-2008).
2.) I change the category from "F/U" to "Rescheduled".
The calendar logic changes that appointment from 09-09-2008 to 09-08-2008 ( today’s date) and it disappears from the time slot on 09-09-2008. It is visible on the time slot on today’s time slot of 09-08-2008.
The current date shows up immediately when attempting to change a future appointment. For example, today is 09-09-08 and I clicked on an appointment for 09-11-08 for which to change the category. When the pop up window appeared, "9-9-08" appeared in the date field. This time I did not change the category and clicked "save." The appointment now moved to 09-09-08.
I suppose the logic is assuming that if you click on a future appointment you are going to change the date. This was not the case in OpenEMR-2.8.3.
Good point Jason. Yes, this is for repeating events.
We have patients that sometime call in advance to re-schedule an appointment. We like to have a log of their appointment history, so we keep the appointment on the calendar, but just change the category to "re-scheduled."
Got it. I believe you’re using an older version of the software where there is a bug with repeating events. The latest software (v2.9.0) addresses this specific problem. If you have the time I suggest trying the newest version. I also suggest trying the new calendar look and feel (a shameless self-promotion for my work on the code base). The ‘Outlook’ style calendar looks more like a real calendar and might be easier for your staff to use.
I am using 2.9.0. I upgraded from 2.8.3. The upgrade did not go so smoothly. I am unable to use any calendar look but the classic ( pink/blue). When I select them in Admin and save, the calendar still defaults to the classic. I am ironing out some issues with GACL as well.
Is it possible for me to take my upgraded openemr database and just import it into a clean install of 2.9.0? One thing I noticed is that 2.9.0 has 76 tables from a clean install, my version of 2.9.0 that was upgraded from 2.8.3 has 73 tables. This 3 missing tables are:
I not very experienced at troubleshooting upgrade problems. Rod or another developer would be better suited to give accurate answers. But I’ll give it a shot anyway…
It seems your database upgrade (you did the upgrade right?) goofed up somewhere along the way. I’ve seen this happen on my server too. The upgrade file ‘<oemrinstall>/sql/2_8_3-to-2_9_0_upgrade.sql’ might fail somewhere in the middle and never finish applying the necessary changes to the MySQL database. Sometimes you’ll get an error message telling you about the failure. Sometimes you won’t.
My solution, and it’s not fun or easy, is to
1) Open the phpMyAdmin tool in the OpenEMR web interface. You get there by click on Admin and then Database.
2) In the phpMyAdmin screen look for the list of tables to the left side of the screen. Click on ‘openemr’, or whatever the name of your OpenEMR database, at the very top of the list of tables.
3) In the right hand part of the screen you should see a few tabs. Click on the one named SQL.
4) Here you should see a text box where you can hand enter SQL commands
…
5) Now go and open the 2_8_3-to-2_9_0_upgrade.sql file in your favorite text editor.
6) Go through, command by command, the entire file. Copy a single command block into the text box in the web interface and execute it.
It’s a tedious process but it might help you determine what’s going wrong.
You may also want to follow the same drudgery with the 2_8_2-to-2_8_3_upgrade.sql file as well.
Now why do I think this is the cause of your troubles??
The calendar interface can only change if you have the field ‘cal_ui’ in your Users table. That was introduced about half-way through the 2.3 to 2.9 SQL conversion script. And the ‘notification’ tables were introduced in the last 100 lines of the SQL script ‘database.sql’ in the same directory as 2_8_3-to-2_9_0_upgrade.sql.
So I think if you can get the odd database upgrade issues sorted out you’ll be in good shape. Try to make the upgrade work before resorting to a fresh install of 2.9. Let us know how you make out.
Thank you for your reply. Yes, I did use the 2_8_3-to-2_9_0_upgrade.sql script. I will try the line by line analysis of the upgrade script. I am familiar with using phpMyAdmin ( great db tool!! )
I did confirm that I have the field "users.cal_ui." For my user id (mike) the value remains set to "1" even after I specified the "outlook" calendar option in the admin section of OpenEMR.
So you’ve got v2.9 of the software which means you can choose ‘Outlook’ as your calendar style. You have cal_ui as a field in the Users table of the database. hmmmm…
Try this, manually change the cal_ui value to ‘3’ for yourself. Log out from OpenEMR and log back in. Do you see a new calendar style?
If so, then there’s most certainly something screwy in this file:
<oemrpath>/interface/usergroup/user_admin.php
There are lines in that file which save the cal_ui value to the database.
I’ve been playing with the Outlook style interface and noticed something odd. When I double-click on a blue block (open time) and a new appointment window pops-up, the repeat box is checked and set to be a weekly repeating event. The time also defaults to 10am with a duration of 0.
Why does this happen?
If I click the add button, this does not occur.
With the old calendar style, we had a time at the left for every doctor and clicking on that time would create a new appt pop-up for that doc at that time. Very handy.
If you double-click on a blue block (In-Office category) then you’ll be editing that In-Office event. You won’t be creating a new event at all. You’re seeing the details of your repeating 10am In-Office event when you double-click in the blue block.
In the Week view of the calendar you can click on a time slot and it defaults to whichever provider’s calendar you are looking at.
In the Day view you can can multiple providers side-by-side. The current version of the software doesn’t let you click on a time because it would be uncertain as to which provider you’d be trying to schedule. However, I agree the ability to click on the time slot is convenient and will work that back into the code for the next release.
I have been caught up with some other tasks for the last week and now I am back to trouble shooting my upgrade issues. I noticed that the the cal_ui value is set to '3 in the database for my user id. However, I am still seeing the classic view. Could this be related to ACL issues? ACL is not working 100% for me since the upgrade.
If your users have cal_ui set to ‘3’ then they should be getting the Outlook style calendar. hmmmm…
I just reviewed some source files of the v2.9.0 release and they look fine. So you *should* be seeing the Outlook style calendars. I think I’m going to need to try a clean install of v2.9 and see what is going wrong.