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

• Commercial Supplement ( condition on another answer in same group)
  and
• pay_method : condition on attribute_3 : if you haven't a tojen table : there are a javascript error (we have a if((()) ....).

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:
http://docs.limesurvey.org/Setting+conditions#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.
I'm afraid I'll have to wait for my holidays to get some time for this (next week), unless you've already figured out what the pb is ?

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