bradymiller wrote on Tuesday, June 28, 2016:
Search for skip_timeout_reset in left_nav script to see use, which then is acted upon in auth.inc here:
sunsetsystems wrote on Tuesday, June 28, 2016:
The problem here is to know on the client side that the reason for leaving the page is session timeout, so we don’t prompt the user to approve the action. I don’t see a connection to skipping the timeout reset.
bradymiller wrote on Tuesday, June 28, 2016:
good point. I misunderstood the comments above. disregard.
-brady
sunsetsystems wrote on Tuesday, June 28, 2016:
This was a bit tricky. I ended up having to change the way the login screen is loaded by auth.inc, so that the beforeunload handlers will know when a timeout has occurred. I think this will also make timeout more robust. Code is here:
https://github.com/sunsetsystems/openemr/commits/beforeunload
Seems to test well here. Anyone see any more gotchas?
yehster wrote on Tuesday, June 28, 2016:
Including extra javascript in auth.inc might cause problems for scripts that are pure AJAX which don’t typically interact with the windows. It might corrupt the expected JSON or XML output.
yehster wrote on Tuesday, June 28, 2016:
Ok. deep look seems that it only gets injected when there is a timeout, so likely not an issue.
sunsetsystems wrote on Tuesday, June 28, 2016:
Thanks for checking Kevin. Probably wouldn’t be good to log out on an ajax request.
medfetch wrote on Sunday, July 03, 2016:
There is nothing worse than losing the data you just entered. I am an idiot and on complex forms I do it too often. I might close the window too early, forget to hit save or talk too much to the patient and leave the room. So I use an autosave function in the Eye Form. Once data is entered and I leave a field, close the form, move to another room for further testing with the same patient or whatever, the data is saved to the server. I don’t have to think about it.
A big problem I ran into with autosave is if the form is open in two places - two computers or even two separate browsers on the same computer. I had to create an unique identifier for each instance, and only one instance is allowed to store saves to the database, the others are in read-ony mode and can “watch” as the main/owner instance updates the record. The read-only instance can take write access, but in doing do it sends any other instance to read-only mode. Ownership lasts for 1 hour, then expires.
Once a record is esigned, it should be done. If it is not esigned, it is not done. I see autosave as an interim step, on the way to being esigned/finalized. If it is important, maybe the reports should have a line to say, “This report has not been finalized - esignature is pending.” or similar? I hadn’t equated this to an autosave feature.
blankev wrote on Monday, July 04, 2016:
Would synchronize the latest INPUT, be a better option? Both forms are stored on the Server, but are different so after INOUT on two computers there is some kind of COPY PASTE needed to get the information into one form. Automatic synchornize seems to be a better option. Not beiung a programmer this is just a thought.
medfetch wrote on Monday, July 04, 2016:
I agree on the auto sync part. Only one set of data exists on the server for a given form/encounter. Any authorized user can read the data but only one person at a time has write priviledges. The others see updates every 15 seconds, if there are any, via an ajax call.
It is already a lot to save the form to the server with each field update - doing it with each input/keystroke would degrade the end-user experience and result in too many calls to the server. Maybe someday the computers and network speeds will be so great we could do this for each keystroke. I think the argument for a “save and continue” button would be that there is no call to the server until the button is pressed – the save is actively performed by the user, as opposed to the computer. I think if you have no bandwidth issues the networking impact of the autosave feature should be minimal and if the doctor entered it onto the form he/she meant to save it anyway. Why wouldn’t we?
juggernautsei wrote on Tuesday, September 06, 2016:
I need to revive this thread because of an issue that we are experiencing. I have attached the screenshot of the Chrome browser is showing the default message and it is throwing off the users.
When they click save and the message pops up do you really want to leave this page and it comes up when they click the save button. It should only popup when they click the cancel button.
Any thoughts? I am looking into this to see how this behaviour can be changed.
sunsetsystems wrote on Tuesday, September 06, 2016:
That would be a bug. The browser-side Save handler is supposed to set the “somethingChanged” variable to false to avoid the message. Can you reproduce it on one of the demo sites?
juggernautsei wrote on Tuesday, September 06, 2016:
I’ll try it out now It happens when you save a lbf then reopen that same lbf and edit it and try to close it again.
I’ll update you in a few:
Ok what i found in the demo is the opposite of the production.
On the demo site I created a LBF and typed in it saved and opened again to see if the warning popped up when clicking saved and it did not. So I tried to navigate away from the page without clicking save and it let me navigate way to another part of the system without warning me that I was about to loose data and data was loss.
Hummm…
We continue to get requests on the level of indignation that LBF forms don’t autosave. @kchapple has a proposal that he thinks will take 24 hrs of work. The current customer is a charity. Are there any other clinics, etc that would be willing to share the cost of this enhancement? We can (as usual) make it a optional feature.
–Tony
Quick Fix
install chrome extension.
Firefox