1. set (because it !== false)
2. does not contain the existing answers, which are in $oResponses[0].

$oResponse = $event->get('response');

isset($oResponse)

$oResponse !== false

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?

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

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:

Code:

$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

Code:

isset($oResponse)

, but this condition will always return true, because of the earlier check on

Code:

$oResponse !== false

. Something that is not false cannot be not set at the same time.

lemmon wrote: So far we have lost numerous responses because we had "Allow multiple responses or update responses with one token" enabled.

Needless to say, this is a very serious problem and unacceptable behavior from a survey application.

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?

3) still has values for the same token in an earlier backup of the exported data

mos3465 wrote: Any suggestions on how to progress?

holch wrote:

3) still has values for the same token in an earlier backup of the exported data

With your setting, this says very little, because you can have more than one response from the same token, as you allow multiple response with the same token.

jelo wrote:

mos3465 wrote: Any suggestions on how to progress?

Open a bugticket, even with an old version. You will receive the answer that your version is old, but you might get the answer that there already is a bugticket for that and it was solved or not.

My point is that there is no way way for a user to "un-select" radio-questions where a selection has been made and submitted before (please refer to the attached image).