Migrated from Redmine #453 | Author: Arian Hojat Status: Closed | Priority: High, I’m very impatient | Created: 2019-11-21
So we embed your widget in a page like so and prefill the data based on the params sent in via the url
like so
so email and phone are prefilled since I take the phone/email
and prepopulate them like so in the widget:
“predefined”:
{
“service”:“1”,
“provider”:“<?php echo $provider; ?>”,
“client”: {
“name”: “<?php echo $patient_name; ?>”,
“email”: “<?php echo $patient_email; ?>”,
“phone”: “<?php echo $patient_phone; ?>”
}
}
and the name field has some extra meta information we use when searching/filtering or reporting.
This link is used in 2 apps, one for patients and one for a CallCenter operators.
When presented to our patients via our 1st Online Screener app, everything is fine.
Each user has their info pre-populated correctly since each person takes the screener on their own computer (and therefore have their own session/cookie, then are done and close their browser eventually).
In our 2nd CallCenter app, we don’t have this luxury as the the CC operator will be on the same computer/browser all day.
we are having issues where the name field doesn’t match the patient’s email/phone for the patients they are screenign.
Some background:
A patient calls our CallCenter phone # and screens on the phone with a CallCenter operator where we collect their information.
They then arrive to a question in our app which creates the Widget link dynamically similar to the link I pasted in 1st sentence (with the dynamic name/phone/email)…
but we were noticing the patient Email+Phone mismatched the information in the Name field.
We were seeing patient information from 1 week ago populated in one field, while the other fields was correct with the current patient information.
I figured out that there is a session/cookie on your domain/iframe that is setup for the widget.
That cookie doesn’t expire really until you close your browser window.
So even though we sent new info to prepopulate in name/email/phone, it still uses the old session data for maybe the Name field in particular (and actually sometimes the Email/Phone seems to use the ‘old’ session data as well).
Is there anyway to expire this data via like an additional javascript param that says for example “‘kill_session_now’: true” in the widget’s javascript setup params. That would be extremely useful.
Otherwise we have to tell our CC operators to open your link in a new Incognito Window each time or close our WebApp/Window each time (they would do this hundreds of times per day per operator since they talk to many patients per hour so we are hoping you can implement a variable like this or give us another solution if a solution/js-param already exists).
Making this high priority as we are already using this in production and we are getting alot of bad data.
Note: the pre-populated widget code i pasted didnt get formatted above… Here it is formatted just so u get an idea what we do (pull the $_GET params and prepopulate for the widget):
Hi, it looks like it is not cookies or session but form autocomplete feature enabled in browser. Please try to turn it off.
I’m slightly skeptical that this is it… as I saw this issue be4 on my own computer last week and I saw your code sets a session cookie called “sess_user_publicv2_${nameofcompany}” on your domain/iframe which after clearing helped clear the issue locally for me. (Note: as we are paying for multiple accounts, the session cookie would be called sess_user_publicv2_arian, sess_user_publicv2_globalaes, sess_user_publicv2_globalaespl, sess_user_publicv2_globalaesde, etc)
But I haven’t been able to replicate today. But my coworker was able to replicate this issue today. So maybe I’ll ask him to record a video, show you that we have autofill turned off in Chrome and yet landing on the page it prefills with old data.
Here is the screenshare video: https://www.screencast.com/t/vmeCl2E76ML
you can see that we send email/phone via the GET params (and i dont think my friend showed but we then set the client javascript prefilled values for name/phone/email… Yet it still uses the old one from earlier today. and also he changes the phone/email again in the url bar manually and it doesn’t work.
He shows the cookie that overrides the prefilled information.
He also shows that Chrome does not have the AutoFill setting on.
He didnt show this as he ran out of 5minutes for the free screenshare program, but after clearing the cookie manually the issue goes away proving that it is a session issue.
This seems like a bug to me that either:
you can say this is a bug and your widget shouldnt function this way… If we supply the provider prefilled info (via the Widgets JS params), dont use the session name/email/phone data as you are currently doing.
or
or leave the current functionality as-is but create a new javascript param called ‘kill_session_now’: true that explicitly clients can opt-in to use which if set to true will kill any previous session/cookie data (and you have to then delete session/cookies if we supply that param)
Hello,
I heard this is a bug/issue and you guys will fix.
Just so I understand the forthcoming fix, is the fix one of these solutions:
If I pass predefined client name/phone/email in the widget code, will it always override (or kill) whatever is in the session/cookie? (so no work from my end needs to be done after you publish this fix)
or
Will there be a new widget/javascript parameter to kill the previous session and start afresh so the predefined client name/phone/email params are respected?
(so some work is needed from my end after you publish this fix [just adding a ‘kill_session_now’: true for example to my widget code])
Either solution sounds fine with me. Just let me know.
Thanks,
Arian
Is there an update on this?
I was mentioned in my CEO’s company-wide email congratulating I.T. for implementing a scheduling solution so fast (but we can’t trust our own scheduling data since the data is corrupted because of this issue). We will launch in many other countries soon so hoping there is a quick fix for this coming soon.
Thanks,
Arian