This appears to be an error in how the conditions editor displays the conditions. The generated relevance equation is correct.

Thibault, my good old friend, any chance you can have a look at this one?

Tom, did you try to reproduce this at an older 1.91 version as well?

Yes, same error in 1.91+. Attaching a sample survey.

the conditions-editor-error.jpg shows what the equations should be.

conditions-editor-error2.jpg shows the conditions editor display for test4, for example.

Hi Guys,

The fact is that this equation was not supported by the old conditions system, and the GUI was built against the old condition system.

When we decided to integrate the EE engine, we said that its GUI would use a simple syntax coloring tool (if user wanted to use new features) thus disabling the GUI. OR it could use the GUI but limitting its capabilities to what was possible in the past.

So this is not a bug, it's just a feature that was never implemented so far.

The odd thing, though, is that 1.91+ would let me create that condition (picking two options for each of three different array sub-questions), but the condition editor does not display the value correctly.

Sounds like we should update the documentation to let people know that they can use the conditions editor to accurately create such conditions, but let them know that in this specific case, the GUI display may be inaccurate, so they should double check the relevance equation to ensure they're getting what they expect.

Humm Weird.
Subquestions were dealt with like different questions.
This means that having both SQ1 == 'foo' with SQ1 == 'bar' must end up beeing ANDed and not ORed.

The only way to build such condition was to developp
(sq1 == 'A' or sq1 == 'B') and (sq2 == 'C' or sq2 == 'D')

===> (sq1 == 'A' and sq2 == 'C') OR (sq1 == 'A' and sq2 == 'D') OR (sq1 == 'B' and sq2 == 'C') OR (sq1 == 'B' and sq2 == 'D')
==> Where OR means "scenario"

So if the GUI lets you write the 1st condition this means that it was modifies by someone who forgot to update the VIEW panel.

To be honest I haven't had a look at the LS codebase since we migrate to Git so it is possible that I missed that.

"Sounds like we should update the documentation to let people know that they can use the conditions editor to accurately create such conditions, but let them know that in this specific case, the GUI display may be inaccurate, so they should double check the relevance equation to ensure they're getting what they expect."

^- I think fixing the GUI would be a better approach :-)

Since it will be very irritating to the user to see the wrong conditions, we should definitely fix this.
Maybe Carsten can help...

I can't see anything wrong done by the conditions editor. The conditions editor never supported the syntax that Thomas claims it should show.
AS Thibault already stated is that conditions on different subquestions are connectet always as 'AND'.

I would say that is an error in the EM conditions2EMsyntax conversion.

Carsten- Please take a look at the attached survey and screen shots. The problem is definitely with how the conditions editor is displaying certain complex conditions. It is ANDing together different sub-questions, but it is not ORing the options within sub-questions. I tested the exact same survey on 1.91+ and see the identical behavior.

yes, but that is how it was intended to work in 1.91+ and earlier versions.
If EM transcripts something different, then EM is not transcripting it correctly.

Carsten, I have to disagree. There must be an error in the conditions editor GUI. When you add the first one or two conditions, the logic looks fine. When you add the third, or try to do some of the conditions described in this and the linked bugs, the conditions editor display suddenly changes to show completely different logic. Then, if you delete or modify one of those conditions, the displayed logic changes again. There is no consistency in the errors generated by the GUI, so that is clearly a bug in the GUI, not EM's conversion process.

Guys, something is very wrong there, see the file I just uploaded (first question group). Build in 191 and broken in 192, mostly due to conversion from inappropriate "OR" to "AND".

Thanks for looking into this
Marc

Marc, which question(s), specifically, are broken?

Many thanks for the quick response!

My questions A1.x and A2.x depend on conditions against their predecessors A1 and A2, which get interpreted badly in release 1.92+ 120611 (which we installed this morning).

However, looking through related issues I think it's actually related to bug 6231, which was only solved less than two hours ago by a release incorporating the fix. Our admin will install the new version now and I'll re-check it on there. Will get back with results once I have them.

Kind regards
Marc

A1.x and A2.x look fine in 1.92+ 120620.

Since 120611 runs an bulk update on conditions and updates your database version to 155.5, you may need to re-run the bulk update process. Options are:
(1) set DBVersion to 155 in the lime_settings_global table and logout/login as administrator - that will re-run the conversion.
(2) Follow the instructions here - http://docs.limesurvey.org/Upgrade+hints+for+version+1.92#How_to_fix_this_problem_if_you_only_use_the_Conditions_Editor

FYI, the question between A1.x and A2 actually combines "AND" and "OR" (as does the final one following A2.x), so I suspect this may still be broken in today's release.

A1++ has this equation:

((is_empty(A1_a.NAOK)) and (is_empty(A1_b.NAOK)) and (is_empty(A1_c.NAOK)) and (is_empty(A1_d.NAOK)) and (is_empty(A1_e.NAOK)) and (A1_f.NAOK == "Y"))

A2++ has this equation:

((is_empty(A2_a.NAOK)) and (is_empty(A2_b.NAOK)) and (A2_c.NAOK == "Y"))

True, it's just a chain of "ANDs", sorry for the confusion.

Many thanks for your help and the hints! Our admin will give me the latest version tomorrow, looking forward to having this fixed - it got me a little stressed shortly before the survey release. :-)

Fix committed to Yii branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=8852

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=8853

Good things come to those who wait. :)

Looks good. Thanks.

New 1.92+ version released.