Reopening a completed survey erases existing responses -- is that normal?

More
2 years 5 months ago #164573 by oleggorfinkel
Hello!

I have a closed-access, non-anonymized survey, with "Enable token-based response persistence" and "Allow multiple responses or update responses with one token" options both set to ON. I've had a few cases when users tried to reopen a completed survey, be it by accident or on purpose (so as to correct something), and when they do that, the survey opens empty, with all the previous responses being lost. This is a serious issue, as it puts completed surveys at risk from plausible actions by users. With the above settings, I would expect that reopening a completed survey should preserve the existing answers -- isn't this correct?

Oleg G.

Please Log in to join the conversation.

LimeSurvey Partners
More
2 years 5 months ago #164574 by c_schmitz
Usually this happens only if the user accidentally open the survey twice and in the second tab of the survey uses the button 'Clear answers & exit' button.
Try removing that button from the theme/template and see if this issue still happens.

Best regards

Carsten Schmitz
LimeSurvey project leader

Please Log in to join the conversation.

More
2 years 5 months ago #164791 by oleggorfinkel

c_schmitz wrote: Usually this happens only if the user accidentally open the survey twice and in the second tab of the survey uses the button 'Clear answers & exit' button.
Try removing that button from the theme/template and see if this issue still happens.


Hi, thanks for replying.

I have actually tested this myself and can confirm that the previous responses are already gone when the survey is reopened, without the user needing to press the "Erase answers and exit" button.

This is happening on version 2.71.1+170927.

Oleg G.

Please Log in to join the conversation.

More
2 years 5 months ago #164792 by oleggorfinkel

jelo wrote:

oleggorfinkel wrote: I've had a few cases when users tried to reopen a completed survey, be it by accident or on purpose (so as to correct something), and when they do that, the survey opens empty, with all the previous responses being lost.

Sound quite normal to me.

You state "Allow multiple responses or update responses with one token".
If the survey is completed and the token is used again, the "Allow multiple responses" is forcing a new survey.


Indeed, that's what I would have expected to happen -- a new, blank survey to be opened. But what IS happening is that the existing, completed survey is REopened with the previous responses erased, gone for good. That's the real problem here... Te version number is 2.71.1+170927.

Oleg G.

Please Log in to join the conversation.

More
2 years 5 months ago #164917 by oleggorfinkel

jelo wrote: We are talking about a respondent, which enters a activated survey via a token.
The respondent is completing the survey.
You can see this survey in the backend under responses.
The respondent enters the survey via token again.
The respondent sees a empty survey.
You no longer have the former completed response of that specific respondent in the backend.

Is that a correct description of your issue?


Yes, this is exactly what's happening.

Oleg G.

Please Log in to join the conversation.

More
2 years 4 months ago #166808 by beth193
Hi, I just thought I'd add some extra input here - I noticed this was happening with my surveys last year, wiping the saved response, and I probably should have raised a ticket or posted here then. But instead, I wrote a php script that is called by ajax on completion of every survey - this script updates the survey table (using details passed by the ajax request) to set submitdate = null, lastpage = 1 for that user's token. This resolved my issue because it allows the user back into their completed response and they can edit it - I wasn't looking for it to create a brand new entry in my case, more the 'edit' that the person above me was also referring to. My customers often want to be able to go back in a 'change' some of their answers but don't want to have to re-enter the whole survey, so I need the 'update response' (instead of 'multiple responses') part of the option.

I have been calling this on every completed survey for ages now so had kind of forgotten about it - I occasionally check new limesurvey versions to see if this is fixed but had kind of given up on it, and since my script worked I never really bothered about it. But since it has been raised by someone else now I thought I'd just add in that yes, this is definitely an issue; I have experienced since at least early last year, but setting a null submitdate and lastpage = 1 resolves it and allows the user back into their completed survey (which is what I wanted, rather than creating a new survey).

So oleggorfinkel, if you need to allow users back into their survey you could always try this method, I know it's a bit hacky but it works!

Please Log in to join the conversation.

More
2 years 4 months ago #166817 by beth193
No... As I said, it never really bothered me so I didn't open a ticket - my workaround works fine for me. I wasn't replying to complain (I only used the word 'issue' because the original post called it that), I was replying to that user to try and help, to let them know other people had the same experience and that there was a way around it if they wanted.

Please Log in to join the conversation.

More
2 years 4 months ago #166851 by Jane

jelo wrote: We are talking about a respondent, which enters a activated survey via a token.
The respondent is completing the survey.
You can see this survey in the backend under responses.
The respondent enters the survey via token again.
The respondent sees a empty survey.
You no longer have the former completed response of that specific respondent in the backend.

Is that a correct description of your issue?

Ouch. Tammo attended me (his business partner) to this topic just now. This is exactly the issue encountered by one of our customers. To see what was going one we developed a plugin that just about logs everything there is to log about actions by participants in a token-based survey. This evening I finished the description of the plugin. See TFR Response Logger plugin .

@oleggorfinkel Could you install and configure this plugin? I hope it gives you a clue at which moment this exactly goes wrong.

Please Log in to join the conversation.

More
2 years 4 months ago #166852 by Jane

beth193 wrote: Hi, I just thought I'd add some extra input here - I noticed this was happening with my surveys last year, wiping the saved response, and I probably should have raised a ticket or posted here then. But instead, I wrote a php script that is called by ajax on completion of every survey - this script updates the survey table (using details passed by the ajax request) to set submitdate = null, lastpage = 1 for that user's token. This resolved my issue because it allows the user back into their completed response and they can edit it - I wasn't looking for it to create a brand new entry in my case, more the 'edit' that the person above me was also referring to.

The plugin, described in my previous reply, has an option that does more than logging. 'Force load of single response' tells it all. If the plugin finds only one response set, it makes sure that this will become the activerecord in the $_SESSION. In other words: it will always enforce the edit of an existing record and never allows opening a new response set if one already exists. Our thought: this should not be needed. After reading this topic: maybe it is needed until the apparent issue in the topic is solved.

FYI: the customer contacted us on January 31, a few weeks before oleggorfinkel opened this topic.

Please Log in to join the conversation.

More
2 years 4 months ago #166859 by Jane
Hi jelo,

jelo wrote: I'm confused and impressed at the same time. You all developed scripts and plugins. Wouldn't it cost a lot less effort to open a bug-report first. "deleting" responses via accessing a link is a red alert.

We could not reproduce it yet. And neither could our customer. Our customer only received reports about blank surveys by respondents, when they should not be blank. So the only option was to log what was going on and analyze what went wrong at the next occurrence.

Of course, we will try to reproduce it now using the information in this topic.

Please Log in to join the conversation.

More
2 years 3 months ago #167106 by Mazi
If I remember correctly we faced a similar issue last year with a token based survey we had set up for WHO. They also reported blank surveys randomly when re-enetering with the same token and using the same settings like "Token based answer persistance".
I couldn't really track it down and was assuming that it was caused by using multiple browsers or tabs at the same time which could mess up session details.

Best regards/Beste Grüße,
Dr. Marcel Minke
Need Help? We offer professional Limesurvey support
Contact: marcel.minke(at)survey-consulting.com
Want to use your survey offline -> www.offlinesurveys.com

Please Log in to join the conversation.

More
2 years 3 months ago #167121 by JanE01
Hi Marcel,

Do you remember if the problems in the WHO case were limited to re-opening surveys that had already been submitted? Both oleggorfinkel and beth193 are indicating this. Was the effect that the existing reponses were wiped?

We tried hard to reproduce the problem, by opening the same survey in different tabs at the same time, opening it in other browsers, leaving sessions open for a really long time. But we never succeeded.

Our TFRResponseLogger plugin learned us that the existing answers are only loaded at the initial opening of the survey. Look at these lines in application/controllers/survey/index.php:
github.com/LimeSurvey/LimeSurvey/blob/ma...urvey/index.php#L540

If ($oResponse !== false), but somehow line 545 is not executed, you end up with a $oResponse that is
  1. set (because it !== false)
  2. does not contain the existing answers, which are in $oResponses[0].
That would explain the vanishing answers. I have no idea yet how $oResponse can !== false and not contain the existing answers.

$oResponse is initially defined in line 536:
$oResponse = $event->get('response');
If this line returns a not false $oResponse without existing answers, but with a set submitdate, line 545 will not be executed and we really are in troubles.

As a BTW: lines 542 and 546 contain a condition
isset($oResponse)
, but this condition will always return true, because of the earlier check on
$oResponse !== false
. Something that is not false cannot be not set at the same time.

Please Log in to join the conversation.

More
2 years 3 months ago #167140 by Mazi

JanE01 wrote: Hi Marcel,

Do you remember if the problems in the WHO case were limited to re-opening surveys that had already been submitted?

Yes, the goal was to let users re-enter any time to update their data set

JanE01 wrote: Hi Marcel,
Both oleggorfinkel and beth193 are indicating this. Was the effect that the existing reponses were wiped?

Yes, if I remember correctly this happened to 1-3 of ~120 data sets.

JanE01 wrote: Hi Marcel,
We tried hard to reproduce the problem, by opening the same survey in different tabs at the same time, opening it in other browsers, leaving sessions open for a really long time. But we never succeeded.

Our TFRResponseLogger plugin learned us that the existing answers are only loaded at the initial opening of the survey. Look at these lines in application/controllers/survey/index.php:
github.com/LimeSurvey/LimeSurvey/blob/ma...urvey/index.php#L540

If ($oResponse !== false), but somehow line 545 is not executed, you end up with a $oResponse that is

  1. set (because it !== false)
  2. does not contain the existing answers, which are in $oResponses[0].
That would explain the vanishing answers. I have no idea yet how $oResponse can !== false and not contain the existing answers.

$oResponse is initially defined in line 536:
$oResponse = $event->get('response');
If this line returns a not false $oResponse without existing answers, but with a set submitdate, line 545 will not be executed and we really are in troubles.

As a BTW: lines 542 and 546 contain a condition
isset($oResponse)
, but this condition will always return true, because of the earlier check on
$oResponse !== false
. Something that is not false cannot be not set at the same time.

Please check the bugtracker for similar issues or - if none found - please create a new ticket and share your details there so the developers can look into this and join the discussion.
Thanks!

Best regards/Beste Grüße,
Dr. Marcel Minke
Need Help? We offer professional Limesurvey support
Contact: marcel.minke(at)survey-consulting.com
Want to use your survey offline -> www.offlinesurveys.com

Please Log in to join the conversation.

More
1 year 4 months ago #181371 by lemmon
I can confirm that this is still happening in version 3.15.9. We are currently running a very complex survey which takes the respondent well over an hour to complete. So far we have lost numerous responses because we had "Allow multiple responses or update responses with one token" enabled. We removed the "Clear Survey" button from the template (Vanilla) before launching, so it is not possible that user action is responsible for this. It also happened to one of the survey admins, who also wanted to take the survey in production. All he did was that he re-visited the link to go back and edit his responses, only to find his data had been wiped.

Needless to say, this is a very serious problem and unacceptable behavior from a survey application. There is no justification whatsoever that it randomly erases respondent data without at least warning the user, contrary to what some of the early respondents to this topic seem to suggest.

Has anyone reported a bug on this in the mean time?

Please Log in to join the conversation.

More
1 year 4 months ago #181723 by DenisChenu

lemmon wrote: I can confirm that this is still happening in version 3.15.9. We are currently running a very complex survey which takes the respondent well over an hour to complete. So far we have lost numerous responses because we had "Allow multiple responses or update responses with one token" enabled. We removed the "Clear Survey" button from the template (Vanilla) before launching, so it is not possible that user action is responsible for this. It also happened to one of the survey admins, who also wanted to take the survey in production. All he did was that he re-visited the link to go back and edit his responses, only to find his data had been wiped.

Has anyone reported a bug on this in the mean time?

What is checked on manual.limesurvey.org/Participant_settin...response_persistence ?

Assistance on LimeSurvey forum and LimeSurvey core development are on my free time.
I'm not a LimeSurvey GmbH member, professional service on demand , plugin development . I don't answer to private message.

Please Log in to join the conversation.

Start now!

Just create your account and start using Limesurvey today.

Register now