Mutiple providers were reviewing patient records. Openmrs started to force them to log out. The providers failed to provide necessary care.
I appreciate your help.
Thanks @dkayiwa
I am not sure how can I do so.
Regarding what happened, I know is that new providers logged in to review the system (around 26 of them). Then, OpenMRS started to kick them out and they have to login in again. I know they all where reviewing the same patient chart when this happened. When less of them login, the system is back to normal.
Did any of them try login with the same accounts? Is this something you can consistently reproduce even on your server? A look at the server logs could also help.
The only way I can do this is to ask them (or other volunteers to redo the process). I am trying to plan this hopefully soon.
Each user has his/her own username. On the server logs (see above), you can actually see them logging at almost the same time with their own usernames.
We where orientating new providers when this happened. we usually do not get that many users login at the same time for the same patient.
mmm … that I am not sure about. What was happening is that they were guided by their supervisor and he was explaining workflow on OpenMRS. They were following his clicks. So I doubt it is a case of having their login expires. I will confirm this when I meet their supervisor.
Anything else I should keep in mind?
Did you find anything in the logs above @dkayiwa
I looked at it too and didn’t find anything clear.
The session location is what seemed to fail:
“javax.script.ScriptException: ReferenceError: “sessionLocation” is not defined in at line number 1”
Was it possible that the supervisor was speaking for a period of time where there was no activity, then asked the users to go to a new screen? You can figure this out by looking at the times in the log before 12:16 on 9-22-17. Was there a significant delay before then?
Also, @dkayiwa Do you know why there’s a save user action logged each time the page is viewed?
@yadamz, this looks like normal behavior and I don’t expect that this is the issue.
I think your best bet is to look at the logs and see when the last time a particular user executed a transaction before the errors started happening at 12:16 on 9-22