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?

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.

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.
As long as the survey isn't completed, the survey with answers can be accessed.


You might provide some more insight about what is really lost from what point of view.
Please state the used LimeSurvey version and try to reproduce the "issue" on your own.
If you deactivate" multiple responses"for tokens, you should always get to the same survey response record for that token. Completed or not.

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.

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.

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?

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.

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!

beth193 wrote: But since it has been raised by someone else now I thought I'd just add in that yes, this is definitely an issue;

The workaround till everything approach is popular in LimeSurvey-LaLaLand.
But an issue without an bugticket is a forgotten issue . And a forgotten issue is no issue at all. Is there a bugticket? If yes, please post the URL here.

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.

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.

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.