@ gwwri:
1) Can you reproduce the problem on v1.87+?
2) If yes, please attach a simple sample survey, where we can reproduce the issue - THX!

I let you try with the latest version and upload a sample survey if the pb is still there.

I upgraded to 1.87+ Build 8518 and made a (relatively) simple test survey to isolate the problem and it still doesn't work. Actually, it seems to be worse. Even simpler branching schemes related to token tables don't work. I'm attaching a test survey structure and a token table with some example values. I set this up to isolate a problem with the branching on a complicated question that looks at multiple token attributes (as described above) but I can't even get a really simple branch to work now. I have this condition here on a few questions:

Is your spouse Jewish?

gets asked if:

-------- Scenario 1 --------

married: are you married? (qid3167) equals Yes (Y)
and
still mar: are you still married to the same person as before? (qid3168) equals No (N)
-------- OR Scenario 2 --------

Was married before [From token table] equals 0 and
married: are you married? (qid3167) equals Yes (Y)

but the questions ALWAYS display, even before I click anything on the first page. Theoretically, these questions, regardless of anything in the token table, should ONLY appear if you say you are married, but they ALWAYS appear.

HELP!

Of course, LS doesn't preserve the token table when you import a survey, so the if condition statements will refer to "ATTRIBUTE_2 [Inexistant token table]" instead of what I specified when you first do look at this survey. You'll have to create 4 different attributes before you can upload the test tokens I've attached. here's what the different attributes should be
1=Was married before
2=Rabbi Officiated wedding
3=was married to someone not raised Jewish
4=married to someone not Jewish now

-G

Please fix your survey as it contains chained conditions without respecting the Chained-Conditions requirements:

http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure=English+Instructions+for+LimeSurvey#Chained_conditions

Then please try again and report if the pb is still there.

Thibault

I've never understood that part of the documentation actually. Specifically the following sentence "In the example above a question is displayed 'Do you like being male?' which has conditions set, and which will only display if the answer to What is your gender? is M. If you were to add a condition to this question requiring a specific answer from the Do you like being male? question, then this question WILL NEVER DISPLAY, because the question Do you like being male will not be presented."

emphasis mine

This language does not appear to gel with my experience about LS, or else I'm not understanding it.

This statement implies, or actually explicitly states that the third question will NEVER be displayed, which is false, it displays just fine, as long as the respondent answers "yes" to "do you like being male." If the respondent isn't male then they don't see the question at all. If they say they're male and they like it, then they get the question, even if the branching only checks on "I like being male." I've done dozens of surveys with, as this puts it "chained conditions" with a question that is conditioned on an earlier conditioned question, and it's always worked fine, even without referencing the first question in the branching logic. So I'm not sure what this section is saying.

Is it saying that I can never have conditions based on questions with previous conditions? Because this is false, I do it all the time.

Or is it saying that If i want to have conditions based on questions with previous condition then I need to refer not only to the conditioned question, but also to the original question that is the basis for the second question? This also appears to be false, because I do chained conditions all the time without referring to the original question.

or is it saying something else?

Maybe it just needs to be reworded. In any case the branching in this survey that doesn't work actually doesn't depend on chained conditions, it only breaks when there are multiple scenarios. In the test survey I sent I was sure to reference the conditioned question AND the original question in the branching and it still doesn't work. if the above section is telling me that I need to do something else as well, then I'm not sure what it is.

In any case I was able to fix this by using Javascript to pipe in answers from the token table to hidden questions on an earlier page of the survey, and everything works fine with the branching I was originally using (which uses chained conditions) so it appears the problem is the way LS is handling grabbing data from token tables, not chained conditions.

[QUOTE]Or is it saying that If i want to have conditions based on questions with previous condition then I need to refer not only to the conditioned question, but also to the original question that is the basis for the second question?[/QUOTE]

Excactly. Even, if it "seems" to be working, the result is unreliable so don't do this if you want a consistent survey.

[QUOTE]Maybe it just needs to be reworded[/QUOTE]

Indeed, it needs to be reworded. This is a wiki so you can do this.
However, the example is quite clear about what the correct setting is.

[QUOTE]In any case the branching in this survey that doesn't work actually doesn't depend on chained conditions, it only breaks when there are multiple scenarios.[/QUOTE]

Please uplaod a simple survey structure without any chained conditions and details step to reproduce the pb then.

Thibault

I've designed a simple survey showing the bug.

Fixed in rev 8643.

Thanks for the report.

Thanks for figuring this out.

I don't feel comfortable making changes to the wiki as I'm not sure exactly what the limitation on branching exactly is. Combining my experience with what you are telling me it seems like using chained conditions without specifying the entire branching logic all the way down the line will generally (all of the time in my experience) work as expected, but is in some sense "unreliable" and might behave illogically, or something like that, in some cases. The example does clearly lay out the kind of structure that you say causes this issue, but it seem to me like the example is saying that a) that the branching as specified will never work at all, even if you explicitly specify the initial branch and b) that this behavior is, in fact logical and totally inline with the specifications, and it's just that the user specified the branching incorrectly. I know now that a) is not true and what it is really saying is that you have to specify the first condition explicitly, however, part of the problem is that, in the abstract, chained conditional logic does make sense. Saying Q3 only gets asked if Q2=1, while knowing that Q2 only gets asked if Q1=1 seem to me like totally sound logic. If setting this condition on Q3 without specifying the condition on Q1 in LS causes the branching to be "unreliable" then that's a software limitation or bug, and needs to be flagged as such, because that sort of logic works fine in every programing language or stats program I've ever used. Logically I shouldn't NEED to tell LS that Q1 has to equal 1 (and, as I've said, in my experience, I haven't needed to), but if you are saying I do, it should be spelled out as an area where the program acts illogically, and you should probably warn people that even though it often LOOKS like this branching works it might not be, in some way. I feel like this needs to be done by someone with an understand of how the source code actually deals with these conditions, which is not me, I don't know php at all, we have an IT person who deals with the code and updates, I'm just the prime user.

I don't mean to be a gadfly about this. I absolutely love LS and the support I've received from the community, thanks again for fixing the bug and thanks for such an awesome program!

-Graham