That file is already corrupted - the SGQA codes for the logic don't match the rest (so it is guaranteed to import wrong).

Can you please attach a file that does work, and we can test whether importing it leads to problems?

When I manually re-create the conditions, export the file, and re-import it, all of the conditions convert properly, including the hidden JavaScript in question q3. Just did this twice (exporting/re-importing) without any trouble.

There were some problems in older release candidates. Perhaps it was an issue there?

I'm attaching the converted survey. I may not have the conditional logic exactly the same, but you get the idea.

Hello Tom,

I just attached the original survey created in Version 1.91+ Build 12416 with its theme. I imported this in Version 1.92 RC5 Build 120225 and the relevance rules and conditions look ok after the import. I even imported the survey again and the relevance and conditions look ok too.

The issue is that q1 ("Congratulations...") does not appear even though it passes the conditions set. Importing the same survey and theme in Version 1.91+ Build 12416 works with no issues.

Is it safe to assume that 1.92 should be backwards compatible and you should not have to redo conditions if you're importing a survey from an older version of lime?

Yes, 1.92 is backwards compatible with three small but unavoidable exceptions:
(1) Any custom embedded JavaScript must have spaces after opening curly braces and spaces before closing curly braces
(2) Such JavaScript using regular expressions containing curly braces within the JavaScript must use quotes around the regular expressions rather than the in-line JavaScript syntax like anSSN.match(/\d{3}-\d{2}-\d{4}/)
(3) Mathematical comparisons against empty - http://docs.limesurvey.org/Expression+Manager+Roadmap#Mathemematical_Comparisons_against_Empty_no_response_

The reason q1 doesn't work in 1.92 is because your regular expressions are not properly formed. The generated relevance equation for q1 is:

((s2.NAOK == "A1") and (regexMatch("[1-2][0-9]", s3.NAOK) or regexMatch("[2-9]", s3.NAOK) or s3.NAOK == "30") and (s4.NAOK >= "30"))

It should be:

((s2.NAOK == "A1") and (regexMatch("/[1-2][0-9]/", s3.NAOK) or regexMatch("/[2-9]/", s3.NAOK) or s3.NAOK == "30") and (s4.NAOK >= "30"))

When I fix the two regular expressions in the conditions editor, the Congratulations message appears as expected.

So, the fact that it works in 1.91 is actually a bug in 1.91. According the the documentation, regular expressions must always start and end with slashes - http://docs.limesurvey.org/Using+regular+expressions&structure=English+Instructions+for+LimeSurvey

I just tested limesurvey_survey_22321.lss with a recent 1.91+ stable release. It doesn't work there either, so if there was a bug in regular expression processing in 1.91, it has been fixed.

Since this is not a bug in 1.92, marking it as resolved.

thank you for this. i just learned something new again. =) so i assume that if the regular expressions had the slashes in the original survey, it would have worked as it should when it was imported in 1.92?

btw when you import questions / question groups with embedded INSERTANS is lime supposed to update those as well?

Yes, it would have worked with the slashes (I tested to confirm).

And yes, when importing, INSERTANS are supposed to be updated (but only if they point to a valid variable name to begin with). If you find any reproducible case where they are not being updated, please open a new bug ticket.

will do. =) thanks.

Hello Tom,

http://docs.limesurvey.org/tiki-index.php?page=Using+Regular+Expressions says:
SPECIAL NOTE: Regular Expressions in Conditions
Note that when using regular expressions in the condition editor, do NOT include the beginning and ending slash.

I just wanted to let you know that it seems that the conditions work with or without the slashes in Version 1.92 Build 120303. =)

Fixed with revision https://github.com/LimeSurvey/LimeSurvey/commit/f2f69355b18d887d3987f128d68aef9a6e88cca0

1.92+ Build 120211 released