We (Aquinas College) just upgraded from V1.92 to Version 2.05+ Build 140703. Conditional logic does not seem to be working. Questions that are supposed to be hidden until a select is made from previous questions are always showing.

Any suggestions?

First a few question:

Why would you upgrade just now to Version 2.05+ Build 140703 when the latest Build is 141?

Is this the case for conditions from old surveys that have been on 1.92? If so, what happens when you create a new survey with new conditions?

I can not answer the first one. I did not do the upgrade.

On the second however converted survey logic was not impacted. The issue appears to exist with only newly created surveys.

Just to get up to date I used the comfortupdate (great addition by the way) to get us to the latest stable build.

When I delete a condition I get the following PHP warning.

PHP warning

Invalid argument supplied for foreach()

/usr/local/www/apache22/data/application/helpers/expressions/em_manager_helper.php(772)

760
761 if (is_null($surveyId))
762 {
763 $sQuery='SELECT sid FROM {{surveys}}';
764 $aSurveyIDs = Yii::app()->db->createCommand($sQuery)->queryColumn();
765 }
766 else{
767 $aSurveyIDs=array($surveyId);
768 }
769 foreach ($aSurveyIDs as $surveyId ) {
770 // echo $surveyId.'<br>';flush();@ob_flush();
771 $releqns = self::ConvertConditionsToRelevance($surveyId,$qid);
772 foreach ($releqns as $key=>$value) {
773 $sQuery = "UPDATE {{questions}} SET relevance=".Yii::app()->db->quoteValue($value)." WHERE qid=".$key;
774 Yii::app()->db->createCommand($sQuery)->execute();
775 }
776 }
777
778 LimeExpressionManager::SetDirtyFlag();
779 }
780
781 /**
782 * This reverses UpgradeConditionsToRelevance(). It removes Relevance for questions that have Condition
783 * @param <integer> $surveyId
784 * @param <integer> $qid

Stack Trace
#0
–
/usr/local/www/apache22/data/application/controllers/admin/conditionsaction.php(368): LimeExpressionManager::UpgradeConditionsToRelevance(null, "6577")

363 // DELETE ENTRY IF THIS IS DELETE
364 if (isset($p_subaction) && $p_subaction == "delete")
365 {
366 LimeExpressionManager::RevertUpgradeConditionsToRelevance(NULL,$qid); // in case deleted the last condition
367 $result = Condition::model()->deleteRecords(array('cid'=>$p_cid));
368 LimeExpressionManager::UpgradeConditionsToRelevance(NULL,$qid);
369 }
370
371 // DELETE ALL CONDITIONS IN THIS SCENARIO
372 if (isset($p_subaction) && $p_subaction == "deletescenario")
373 {

#1
unknown(0): conditionsaction->index("editconditionsform", "22785", "129", "6577")
#2
+
/usr/local/www/apache22/data/framework/web/actions/CAction.php(108): ReflectionMethod->invokeArgs(conditionsaction, array("editconditionsform", "22785", "129", "6577"))
#3
–
/usr/local/www/apache22/data/application/core/Survey_Common_Action.php(99): CAction->runWithParamsInternal(conditionsaction, ReflectionMethod, array("subaction" => "editconditionsform", "surveyid" => "22785", "gid" => "129", "qid" => "6577", ...))

094 $oMethod = new ReflectionMethod($this, $sDefault);
095 }
096
097 // We're all good to go, let's execute it
098 // runWithParamsInternal would automatically get the parameters of the method and populate them as required with the params
099 return parent::runWithParamsInternal($this, $oMethod, $params);
100 }
101
102 /**
103 * Some functions have different parameters, which are just an alias of the
104 * usual parameters we're getting in the url. This function just populates

#4
+
/usr/local/www/apache22/data/framework/web/CController.php(308): Survey_Common_Action->runWithParams(array("subaction" => "editconditionsform", "surveyid" => "22785", "gid" => "129", "qid" => "6577", ...))
#5
+
/usr/local/www/apache22/data/framework/web/CController.php(286): CController->runAction(conditionsaction)
#6
+
/usr/local/www/apache22/data/framework/web/CController.php(265): CController->runActionWithFilters(conditionsaction, array())
#7
–
/usr/local/www/apache22/data/application/controllers/AdminController.php(169): CController->run("conditions")

164 $this->redirect(array('/admin/authentication/sa/login'));
165 }
166
167 }
168
169 return parent::run($action);
170 }
171
172 /**
173 * Routes all the actions to their respective places
174 *

#8
+
/usr/local/www/apache22/data/framework/web/CWebApplication.php(282): AdminController->run("conditions")
#9
+
/usr/local/www/apache22/data/framework/web/CWebApplication.php(141): CWebApplication->runController("admin/conditions/sa/index")
#10
+
/usr/local/www/apache22/data/framework/base/CApplication.php(180): CWebApplication->processRequest()
#11
+
/usr/local/www/apache22/data/index.php(207): CApplication->run()

I'm having similar issues. See www.limesurvey.org/en/forum/design-issue...oken-attribute_1-yes

That is weird. I would have expected it to happen with the old surveys and not the new ones... hmmm

I'm having problems with conditions too. LimeSurvey version is V2.05+ Build 141020.

The TOKEN:ATTRIBUTE variables get removed from the conditions when I change any of the questions in my survey. The show up correctly in the editing view of the rule but in the logic file they do not show up.

Example:

Show question tausta11 .... IF

group from attributes equals erl ... AND tausta10 equals Y



but in the logic file it says only ((tausta10.NAOK == "Y")) while it should say ((TOKEN:ATTRIBUTE_2 == "erl")) AND ((tausta10.NAOK == "Y"))



If I remove the TOKEN:ATTRIBUTE rule and re-add it then it shows up right in the logic file, but if I change ANY of the question in the survey (i.e. add another option for another question) all the TOKEN:ATTRIBUTE_2 AND ((another rule)) rules in the survey get modified so that the TOKEN:ATTRIBUTE_2 rule gets removed... and this skrews up the whole survey logic.

Here are the screenshots from FileMerge about the error described above. I did an export of the survey before adding the answer option to a question and after and compared the lss -files. The question was not related to any rules in the survey.



... and this is what happeds to ALL of the AND rules in the survey after doing so ...



So... <relevance><![CDATA[((TOKEN:ATTRIBUTE_2 == "eval") and (241992X1X9.NAOK == "Y"))]]></relevance>

becomes

<relevance><![CDATA[((241992X1X9.NAOK == "Y"))]]></relevance>

There might be a bug somewhere? I want to use the ATTRIBUTE to assign pre-defined groups for the participants.

Please file a bug report and...

1. Give as much information as possible.
2. Provide step-by-step instructions how to reproduce the problem.
3. Provide screenshots and/or a sample survey.
4. Post the link to the bug here so we can follow the progress.

I filed a bug report

bugs.limesurvey.org/view.php?id=9344

Bug #9344 closed and fixed in build 141126

seems to be working :woohoo:

Thanks!

J