View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
05617 | Bug reports | Conditions | public | 2011-11-30 16:05 | 2012-01-30 18:41 |
Reporter | fairsay | Assigned To | lemeur | ||
Priority | high | Severity | partial_block | ||
Status | closed | Resolution | fixed | ||
Product Version | 1.91+ | ||||
Fixed in Version | 1.92RC3 | ||||
Summary | 05617: Using conditions results in blank answers | ||||
Description | In Version 1.91+ Build 11379 (latest as of the time of reporting), I've discovered that using conditions (branching) seems to prevent answers on which conditions are being set from being saved in the database (I've checked the mySQL answer table). I noticed it occurred for a range of answer types (at least List (radio), long free text, list (dropdown)) when conditions were set. I was using conditions set on both token values and previous-question answers. The theme (template) didn't seem to affect it (am using a custom one but tried with a different one). The survey is non-anonymous, uses tokens or registration and groups answers. There are about 20 questions. I went through each possibility step-by-step and it was only by removing the condition that answers were stored again. | ||||
Steps To Reproduce | Set conditions on a question and then complete the survey - it should show blank for each question with a condition (not sure what other factors affect it - see description above). | ||||
Tags | No tags attached. | ||||
Attached Files | tokens_88778.csv (259 bytes)
tid,firstname,lastname,email,emailstatus,token,language,validfrom,validuntil,invited,reminded,remindercount,completed,usesleft, attribute_1 <Org type>, attribute_2 <Status>, attribute_3 <Exception Type>, attribute_4 <Last Event>, attribute_5 <Event Count> tokens_43961.csv (233 bytes)
tid,firstname,lastname,email,emailstatus,token,language,validfrom,validuntil,invited,reminded,remindercount,completed,usesleft, attribute_1 <Org type>, attribute_2 <Status>, attribute_3 <Exception Type>, attribute_4 <Last Event> | ||||
Bug heat | 12 | ||||
Complete LimeSurvey version number (& build) | 11379 | ||||
I will donate to the project if issue is resolved | Yes | ||||
Browser | Firefox & Safari | ||||
Database type & version | MySQL 5.1 | ||||
Server OS (if known) | Linux | ||||
Webserver software & version (if known) | Apache | ||||
PHP Version | 5.x | ||||
Did the condition remove the ability of answer ? Can you send a example survey ? |
|
The condition allowed the question to be answered (it only displayed if the condition was met via the citronaid template/theme) and everything seemed to go well - until it came time to display the answers and then there was nothing on the answers page and nothing (NULL value) in the survey table. I can re-add a few conditions to the survey and upload it here shortly. |
|
I've just attached the lss file export (which I can't get to import correctly into my installation but hopefully you can). Note this is using 'lime survey' as a registration form since the functionality is very similar for intelligent forms (using conditions). I also use it for surveys :-) |
|
I can't confirm the bug, except if you have not a token table. The condition i've found are for
With token table (with more than 3 attribute ): it seemed to work like a charm |
|
Odd. I've repeated the test 20-30 times under a wide range of scenarios (changing one thing at a time) and it occurred (and is still occurring) for me. I do have a token table with four custom attributes. How did you get it to import (I know how to import a survey, but when I try it always reports errors)? I can start with re-creating it from n import to see if I can get it working another way. Would it make a difference if I said this was a version f LimeSurvey upgraded to 1.91+ via the built-in upgrade tool? |
|
Can you export and attach the token data which you use to reproduce the problem? |
|
Attached is a export of the token format - but it is empty because that I how I was testing it: from initially registering to completion and thus a token was added on initial registration and attribute_3 was blank. So by my understanding, the token table shouldn't be a factor in this. It might be something with my install version (not sure why!) so I might try a fresh install and see if that fixes it. |
|
OK - after using the 'duplicate survey' feature, and trying it on this 'fresh' copy of the survey, the problem SEEMED to go away on simple tests. However on re-applying the original conditions to the duplicated survey, the problem re-appears. So I've uploaded the full version of survey with full conditions and hopefully you can replicate the problem where fields like org_fee, training, spfund and some other questions result in no value (a NULL value in the responses (survey_43691 table). My test was when org_type = commercial (com) |
|
will try to have a look this WE. |
|
UPDATE: I am gradually adding back simple conditions and testing after each one. So far, all data is stored and yet in survey export 43961 it still fails. So what I'm guessing is that in survey 43961 (attached above) the mix of conditions is causing the problem. What I don't know yet is what mix! |
|
If I were you I would double check Chained conditions: Failing to conform to this restriction can result in the pb you're seeing. |
|
I don't think chained conditions are the cause for the reason that the questions actually show up but despite being completed on the survey, they are not stored. In the export 43961 I have used scenarios (which I haven't in my working version) but I haven't yet tested if that causes this. |
|
Unfortunately badly chained conditions can prevent responses for displayed questions not to be recorded: this is because conditions are also evaluated at submit time in order to reset any "not displayed" questions. Howevere, this latest evaluation is not done using the same codebase, and thus can end up with different evaluations if the conditions don't respect the requirements. |
|
According to a forum statement by the user the problem could only be reproduced at one special survsey and re-setting the condition solves the problem. -> closed |
|
Note: the forum post is out-of-date. I thought I had solved the problem and then it continued to be present. The most up-to-date info is on this ticket. |
|
I've been sick for the last couple of days as my children were so I wasn't able to have a look yet. Thibault |
|
Hi Thibault, I'm hoping I can get back to testing for the issue next week - so hopefully you can wait :-) |
|
fairsay- 1.92 RC1 should fix any conditions and chained condition issues. Cay you test it on that version? -Tom |
|
OK - I'll try this - although am slightly nervous because it will be upgrading a site with live surveys. |
|
1.92 properly handles the database when there are conditions. All irrelevant values are set to NULL in the database. This ensures that the database is internally consistent. |
|
1.92RC3 released |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2011-11-30 16:05 | fairsay | New Issue | |
2011-11-30 16:05 | fairsay | Status | new => assigned |
2011-11-30 16:05 | fairsay | Assigned To | => lemeur |
2011-11-30 16:13 | DenisChenu | Note Added: 16719 | |
2011-11-30 16:20 | fairsay | Note Added: 16720 | |
2011-11-30 16:26 | fairsay | File Added: limesurvey_survey_88778-2.lss.xml | |
2011-11-30 16:28 | fairsay | Note Added: 16721 | |
2011-11-30 16:39 | fairsay | Note Edited: 16720 | |
2011-11-30 16:54 | DenisChenu | Note Added: 16722 | |
2011-11-30 17:14 | fairsay | Note Added: 16723 | |
2011-11-30 18:37 | fairsay | Note Edited: 16723 | |
2011-11-30 20:03 | Mazi | Note Added: 16724 | |
2011-11-30 22:08 | fairsay | File Added: tokens_88778.csv | |
2011-11-30 22:12 | fairsay | Note Added: 16725 | |
2011-11-30 22:48 | fairsay | Note Added: 16726 | |
2011-11-30 22:50 | fairsay | Note Edited: 16726 | |
2011-11-30 23:21 | fairsay | Note Edited: 16726 | |
2011-11-30 23:21 | fairsay | File Added: limesurvey_survey_43961.lss.xml | |
2011-11-30 23:22 | fairsay | File Added: tokens_43961.csv | |
2011-11-30 23:25 | fairsay | Note Edited: 16726 | |
2011-12-01 09:29 | lemeur | Note Added: 16727 | |
2011-12-01 10:59 | fairsay | Note Added: 16728 | |
2011-12-01 14:26 | lemeur | Note Added: 16729 | |
2011-12-01 14:54 | fairsay | Note Added: 16730 | |
2011-12-01 15:02 | lemeur | Note Added: 16731 | |
2011-12-01 17:16 | Mazi | Note Added: 16732 | |
2011-12-01 17:16 | Mazi | Status | assigned => closed |
2011-12-01 17:16 | Mazi | Resolution | open => unable to reproduce |
2011-12-01 17:29 | fairsay | Note Added: 16733 | |
2011-12-01 17:29 | fairsay | Status | closed => feedback |
2011-12-01 17:29 | fairsay | Resolution | unable to reproduce => reopened |
2011-12-12 14:57 | lemeur | Note Added: 16751 | |
2011-12-16 09:02 | fairsay | Note Added: 16752 | |
2011-12-16 09:02 | fairsay | Status | feedback => assigned |
2011-12-20 22:17 | TMSWhite | Note Added: 16754 | |
2011-12-26 13:32 | fairsay | Note Added: 16757 | |
2012-01-20 16:16 | TMSWhite | Note Added: 16860 | |
2012-01-20 16:16 | TMSWhite | Status | assigned => resolved |
2012-01-20 16:16 | TMSWhite | Resolution | reopened => fixed |
2012-01-24 21:35 | c_schmitz | Fixed in Version | => 1.92RC3 |
2012-01-30 18:41 | c_schmitz | Note Added: 17077 | |
2012-01-30 18:41 | c_schmitz | Status | resolved => closed |