cbezuidenhout wrote on Tuesday, January 31, 2012:
done here is the commit, I also added a button in the top frame, for sending a reminder
commit : https://github.com/tajemo/openemr/commit/f0936030c24c80ce25f50c00e2fa6f90dd0e49c2
branch : https://github.com/tajemo/openemr/tree/datedReminders
- Craig
Tajemo Enterprises
cbezuidenhout wrote on Tuesday, January 31, 2012:
latest commit : https://github.com/tajemo/openemr/commit/8b769115cbb8b61820ecfc75405d7da885ce3d47
branch : https://github.com/tajemo/openemr/tree/datedReminders
- Craig
Tajemo Enterprises
bradymiller wrote on Tuesday, January 31, 2012:
Wow,
That is so cool and minimal code, so I have committed this to sourceforge. Regarding the session timeout issue, I’ll leave it open tonight and see if it timeouts (since now using this autocheck feature in both the messages.php and left_nav.php script now.
-brady
bradymiller wrote on Tuesday, January 31, 2012:
2 things:
1) Just committed minor bug fix (placed a missing top.restoreSession(); call)
2) The timeout function appears to be broken by the auto refresh call. But think there is a simple work-around. Code that checks for timeout is here in library/auth.inc:
if (!isset($_SESSION["last_update"])) {
authLoginScreen();
} else {
//if page has not been updated in a given period of time, we call login screen
if ((time() - $_SESSION["last_update"]) > $timeout) {
newEvent("logout", $_SESSION['authUser'], $_SESSION['authProvider'], 0, "timeout");
authCloseSession();
authLoginScreen();
} else {
if (empty($GLOBALS['DAEMON_FLAG'])) $_SESSION["last_update"] = time();
}
}
So, I think just making a parameter called skip_timeout=1 in the script calls of the repeater functions; can then use this parameter to skip the $_SESSION = time() command. This should effectively provide a mechanism to not incorporate the auto functions into the timeout mechanism.
thoughts?
-brady
yehster wrote on Tuesday, January 31, 2012:
Just trying to re-iterate what you are suggesting for #2 to see if I understand
You are going to change this code
if (empty($GLOBALS['DAEMON_FLAG'])) $_SESSION["last_update"] = time();
to something like
if (empty($GLOBALS['DAEMON_FLAG']) && empty($skip_timeout)) $_SESSION["last_update"] = time();
Then a polling script can put
$skip_timeout=true;
somewhere before it includes globals.php
(near the stop fake register and sanitize escape settings.)
arnabnaha wrote on Tuesday, January 31, 2012:
HI…
Thanks for the awesome counter contribution…works flawlessly…
bradymiller wrote on Tuesday, January 31, 2012:
Yep,
But was just gonna place the skip_timeout=1 as a variable within the javascript function that calls the script repeatedly:
function getReminderCount(){
top.restoreSession();
$.post("<?php echo $GLOBALS['webroot']; ?>/library/ajax/dated_reminders_counter.php",
{ skip_timeout: "1" },
function(data) {
$("#reminderCountSpan").html(data);
// run updater every 60 seconds
var repeater = setTimeout("getReminderCount()", 60000);
});
}
(or something like that)
-brady
bradymiller wrote on Tuesday, January 31, 2012:
And then the auth.inc line would be:
if (empty($GLOBALS['DAEMON_FLAG']) && empty($_REQUEST['skip_timeout'])) $_SESSION["last_update"] = time();bradymiller wrote on Tuesday, January 31, 2012:
probably make the token skip_timeout_update to make it more clear also
ajperezcrespo wrote on Tuesday, January 31, 2012:
I see that the SEND to are check boxes. Won’t this be awkward in large environments? Maybe a pulldown might be more adequate?
Alfonso
bradymiller wrote on Wednesday, February 01, 2012:
Hi,
Here’s a solution for the OpenEMR timeout issue which is testing well:
http://github.com/bradymiller/openemr/commits/dated-reminders-sessions-fix_1
-brady
cbezuidenhout wrote on Wednesday, February 01, 2012:
@Alfonso, yes I agree, the check-boxes are just so easy for users, perhaps a multi-select combo box would be better suited.
@Brady, I like the ability to skip the time-out. mechanism
- Craig
Tajemo Enterprises
bradymiller wrote on Wednesday, February 01, 2012:
Hi,
Just committed the above OpenEMR timeout issue fix to sourceforge.
-brady
aethelwulffe wrote on Monday, February 06, 2012:
integrated and tested from last night’s dev tip.
First, the reminders in the message area aren’t that useful for things like !Hey! stop! you client needs a new treatment plan!. That should still be a global setting option to display high level reminders in the title bar.
Next is a real problem. I set a reminder for patient 899, but the name for patient 898 shows up!
Bug-o-licious.
Best to test this stuff against a large database.
aethelwulffe wrote on Monday, February 06, 2012:
….not that this bug is necessarily the originators fault, and not that it wouldn’t have shown up in a smaller database I imagine….
Anywho I have been trying to track down where the pid gets decremented, and no luck yet.
BTW, where do you suggest adding require_once ‘…/dated_reminders/dated_reminders.php’; into the main title to get this to work if desired?
aethelwulffe wrote on Monday, February 06, 2012:
A little amplification: Discovered that the link to the patient is correct despite the wrong name. It’s just the display of the name that is broken.
aethelwulffe wrote on Monday, February 06, 2012:
Found the original top menu version of the code organization in the readme file…thanks for providing some documentation! This is done too seldom. I wish we could make a habit of popping “feature documentation” into the docs area, and creating a menu there.
Actually, that sounds like a really nice project in of itself….a little HTML page or php that looks for files in it’s folder and displays them as a list when you hit the “manual” button.
aethelwulffe wrote on Monday, February 06, 2012:
HA!
It wasn’t tested against a large database. It decrements PID’s over two digits! Usa a patient with ID 99 or less, and you are good to go. Try 100, and you get 99!
Seems like there are TWO files named dated_reminders.php…not fun. Didn’t realize that until I saw that it was included in a file with the same name….blew my little brain for a bit.
Looks like the issue is somewhere in library/dated_reminders.php. Table data was accurate looking, but I imagine that there might be some structure issues, since I can’t find a - or a -= looking dealie, and php sql queries with arrays make my eyes hurt to look at.
aethelwulffe wrote on Monday, February 06, 2012:
Somewhere here???:
// ----- sql statement for getting uncompleted reminders (sorts by date, then by priority)
$drSQL = sqlStatement(
"SELECT
dr.pid, dr.dr_id, dr.dr_message_text,dr.dr_message_due_date,
u.fname ffname, u.mname fmname, u.lname flname
FROM `dated_reminders` dr
JOIN `users` u ON dr.dr_from_ID = u.id
JOIN `dated_reminders_link` drl ON dr.dr_id = drl.dr_id
WHERE drl.to_id = ?
AND dr.`message_processed` = 0
AND dr.`dr_message_due_date` < ADDDATE(NOW(), INTERVAL $days_to_show DAY)
ORDER BY `dr_message_due_date` ASC , `message_priority` ASC LIMIT 0,$alerts_to_show"
, array($userID)
);
// --------- loop through the results
for($i=0; $drRow=sqlFetchArray($drSQL); $i++){
// --------- need to run patient query seperately to allow for reminders not linked to a patient
$pSQL = sqlStatement("SELECT pd.title ptitle, pd.fname pfname, pd.mname pmname, pd.lname plname FROM `patient_data` pd WHERE pd.id = ?",array($drRow['pid']));
$pRow = sqlFetchArray($pSQL);
// --------- fill the $reminders array
$reminders[$i]['messageID'] = $drRow['dr_id'];
$reminders[$i]['PatientID'] = $drRow['pid'];
// ------------------------------------- if there was a patient linked, set the name, else set it to blank
$reminders[$i]['PatientName'] = (empty($pRow) ? '' : $pRow['ptitle'].' '.$pRow['pfname'].' '.$pRow['pmname'].' '.$pRow['plname']);
// -------------------------------------
$reminders[$i]['message'] = $drRow['dr_message_text'];
$reminders[$i]['dueDate'] = $drRow['dr_message_due_date'];
$reminders[$i]['fromName'] = $drRow['ffname'].' '.$drRow['fmname'].' '.$drRow['flname'];
// --------- if the message is due or overdue set $hasAlerts to true, this will stop autohiding of reminders
if(strtotime($drRow['dr_message_due_date']) <= $today) $hasAlerts = true;
}cbezuidenhout wrote on Monday, February 06, 2012:
a quick question that may be a clue to this bug, I still can’t recreate this bug.
when you linked the reminder to a patient, did you use the “linking” mechanism in the new reminder popup or did you open the patient record in OpenEMR and then send a new reminder ?
have you checked in the dated_reminders table if it is storing the patient id incorrectly ?
- Craig
Tajemo Enterprises