I’ve noticed since upgrading to version 4.0.0 release that the OpenEMR mobile portal no longer works, some kind of user authentication error.
I will be working on it over the weekend, just wondered if anyone else used the mobile portal & had seen the same issue.
That particular bunch of code has apparently not been updated in quite some time, so no big surprise that it’s broken.
One more thing to fix…
Thanks Alfonso! I somehow missed that things were changed to SHA in the final release of 4.0. I was looking at all the wrong things trying to see where the authentication was breaking down.
I tried installing the mobile add-on. I downloaded the files and put them in the openemr root folder. I edited the /mobile/db/dbfunc.php and also checklogin.php and set the correct DB name , password etc. I am able to see the log in page and when I login using the user name and PW I get a blank page. Can you help me?
I would appreciate your kind assistance. As per Alfonso I also changed the encryption to SHA. I am getting to the log in page and when I enter the user name and password I get a blank page. Can you help me please?
Incidentally there are two checklogin.php, one under main folder and the other under simple folder. The setting seems to be fairly simple but looks I am doing something not right.
Is anyone noticing that the SQL is off on the mobile calendar? The appointments on the mobile calendar do not match the appointments displayed on the calendar of my OpenEMR 4.0 installation. I am going to look into the SQL and see what is going on.
Chak,
What is in your apache log? See if you have any errors listed there.
Mike
Yup I have seen that before. After exchanging several emails with the developer of Mobile he said it was something off in SQL. I had no time at the moment to pursue it, but when I had time to look into it it had cleared up. No changes in code. So I have no clues except what the developer mentioned.
This is pretty cool now that I have it working. I had to make a couple of adjustments to the SQL though.
1. JOIN on patient_data.pid rather than patient_data.id.
I have some records where patient_data.pid is not equal to patient_data.id. This was why the mobile calendar was different than my full installation.
2. I adjusted the WHERE clause of the provider list box to only include providers that have users.calendar = 1. I only wanted to display providers that had a visible calendar in OpenEMR to only display on the mobile version.
Another thing I noticed is that the calendar events “In Office” and “Out of Office” will display X number of times per number of providers when viewing all providers. Also, “In Office” and “Out of Office” will not be visible on every day due to setting WHERE clause on openemr_postcalendar_events.pc_eventDate. If “In Office” is a recurring event, it will be excluded when focusing solely on pc_eventDate.
We had the same issue. Here is what works most of the times but some times it displays ‘Data error’:
$qs = "SELECT pid, concat(fname,’ ‘,lname) as name, pc_startTime, pc_catname, pc_hometext " .
"FROM openemr_postcalendar_events as e LEFT OUTER JOIN patient_data as p ON e.pc_pid = p.pid " .
"LEFT JOIN openemr_postcalendar_categories as c ON e.pc_catid = c.pc_catid ";
//use today’s date
if(is_null($date) || empty($date) || is_numeric($date)) {
$where_date = “CURDATE()”;
}
else {
//use a user specified date
//fix date issue
list($year, $month, $day) = split(’’, $date);
$month=$month+1;
Thanks for the code snippet. I will give that a try. I am also considering just limiting the mobile calendar to only view appointment times and avoid this recurring events headache.
BTW - Are the postcalendar tables the best design for a calendar component?
The SQL is from the appointments report so it should take care of recurring appointments as well as multiple physicians related issue.
As far as dropping the recurring appointments, we have seen the recurring events used extensively for physician’s meetings, patient’s routine exams etc. So eliminating that feature would not be cool.
The OpenEMR project is a normal case where code contributions without overall external framework makes maintenance & enhancements a challenge. Since the code is ‘free’, these costs are not visible to most. So the codebase gets more complex as time goes by.
Without getting into the design merits of current database, if major features like calendar get class wrappers, we will not have to dig code in different scripts. But that is effort for another day.
As far as dropping the recurring appointments, we have seen the recurring events used extensively for physician’s meetings, patient’s routine exams etc. So eliminating that feature would not be cool.
I am using recurring appointments in a limited fashion at the moment with just “In Office” and “Out of Office” events. I see your point with “meetings” and other potentially recurring events. Thanks for sharing the other uses I have not really considered.
I try to use this mobile-login feature, but DO NOT SUCCEED!
I think I changed every file as stipulated in the PDF, but I get the following error messages:
Warning: mysql_real_escape_string() : Access denied for user ‘pimmiq’@‘localhost’ (using password: NO) in /home/pimmiq/public_html/mobile/simple/main.php on line 74
Warning: mysql_real_escape_string() : A link to the server could not be established in /home/pimmiq/public_html/mobile/simple/main.php on line 74
Warning: mysql_real_escape_string() : Access denied for user ‘pimmiq’@‘localhost’ (using password: NO) in /home/pimmiq/public_html/mobile/simple/main.php on line 75
Warning: mysql_real_escape_string() : A link to the server could not be established in /home/pimmiq/public_html/mobile/simple/main.php on line 75
Warning: mysql_real_escape_string() : Access denied for user ‘pimmiq’@‘localhost’ (using password: NO) in /home/pimmiq/public_html/mobile/simple/main.php on line 78
I suppose it has to do with the connection to the MySQL database. I can login with normed web based loging screen and do whatever needed to be done, but mobile with the same setting in the DB connection file does not seem to work… ANY advise is welcome.