- Posts: 5056
- Thank you received: 1267
Ask the community, share ideas, and connect with other LimeSurvey users!
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.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.
I understand. But I still would recommend to open a bugticket first. The core developer team seems to like to follow the mantra release early, release often. The natural reaction for that mantra seems to be report early, report oftenJane wrote: We could not reproduce it yet. And neither could our customer
$oResponse = $event->get('response');
isset($oResponse)
$oResponse !== false
Yes, the goal was to let users re-enter any time to update their data setJanE01 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, if I remember correctly this happened to 1-3 of ~120 data sets.JanE01 wrote: Hi Marcel,
Both oleggorfinkel and beth193 are indicating this. Was the effect that the existing reponses were wiped?
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.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 isThat would explain the vanishing answers. I have no idea yet how $oResponse can !== false and not contain the existing answers.
- set (because it !== false)
- does not contain the existing answers, which are in $oResponses[0].
$oResponse is initially defined in line 536: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.Code:$oResponse = $event->get('response');
As a BTW: lines 542 and 546 contain a condition, but this condition will always return true, because of the earlier check onCode:isset($oResponse). Something that is not false cannot be not set at the same time.Code:$oResponse !== false
lemmon wrote: So far we have lost numerous responses because we had "Allow multiple responses or update responses with one token" enabled.
As far as I'm aware of LimeSurvey has no QA-team. The people which download the released version are the QA-team. Automated tests are used more and more. But testing the application with real surveys is something different.Discussing issues in the forum first, will delay bugtickets. Even if the bug is no bug, the bugticket might indicate a UI issue.Needless to say, this is a very serious problem and unacceptable behavior from a survey application.
What is checked on www.limesurvey.org/manual/Participant_se...response_persistence ?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?
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.3) still has values for the same token in an earlier backup of the exported data
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.mos3465 wrote: Any suggestions on how to progress?