View Issue Details

This bug affects 1 person(s).
 4
IDProjectCategoryView StatusLast Update
04974Bug reportsConditionspublic2011-04-11 11:34
Reportergwwri Assigned Tolemeur  
PriorityhighSeveritypartial_block 
Status closedResolutionfixed 
Product Version1.87+ 
Fixed in Version1.91RC6 
Summary04974: "greater than" condition logic dosent deal with number bigger than 10
Description

If you have a list radio or dropdown question (call it question A) with 12 options, and you want another question (B) to only appear if someone selects the top 9 (or whatever) options in question A you would naturally set up the condition as

Only show Question B IF
question A >= 3 (or whatever the lowest number you want to get question B)

This works fine for answer values 2-9 but whatever your values are for options 10, 11, 12 or whatever, they don't work. People who click "7" get the question, but people who click "10" do not.

I suspect that this has something do with the fact that Lime is evaluating the answers as a string (where "2" >"10") rather than a number (where 10>2). But these are just answer codes, so why evaluate them as strings?

Anyways, this is a fairly basic condition, so I'm surprised I never caught it before.

Steps To Reproduce

Follow the steps above. Just create 2 questions, one with more than 10 options and try a "greater than or equals" (or just "greater than") branch off of the first one, then click anything bigger than 10. If anyone wants I'll send a dirt simple survey file that reproduces this bug explicitly.

TagsNo tags attached.
Bug heat4
Complete LimeSurvey version number (& build)8518
I will donate to the project if issue is resolvedNo
BrowserFirefox
Database type & versionSQL server 2005
Server OS (if known)Windows server 2003
Webserver software & version (if known)IIS
PHP Version5.2

Users monitoring this issue

There are no users monitoring this issue.

Activities

lemeur

lemeur

2011-02-22 22:14

developer   ~14262

you version is really old.
This has been "solved" a while ago.
In fact only numerical questions were using numerical comparizons.

Now comparizons are numerical by default unless you use the specific string comparizon operators.

gwwri

gwwri

2011-02-24 18:28

reporter   ~14285

Hmm. The reason we haven't updated is because when we tried going to 1.9 on our devserver it broke all the branching and formatting on our active surveys and runs reeeeeeeeealy slowly, which is apparently a thing other people have noticed.

http://www.limesurvey.org/es/forum/installation-a-update-issues/52305-horrible-performance-in-190

We're trying to survey 60,000 people right now, so this is not something we can risk. So we for sure can't update until all of our surveys are out of the field, which won't be for a while it looks like.

Oh well. We'll try to fix this in the code ourselves.

Issue History

Date Modified Username Field Change
2011-02-22 21:40 gwwri New Issue
2011-02-22 21:40 gwwri Status new => assigned
2011-02-22 21:40 gwwri Assigned To => lemeur
2011-02-22 22:14 lemeur Note Added: 14262
2011-02-22 22:14 lemeur Status assigned => resolved
2011-02-22 22:14 lemeur Resolution open => fixed
2011-02-24 18:28 gwwri Note Added: 14285
2011-04-11 11:34 c_schmitz Fixed in Version => 1.91RC6
2011-04-11 11:34 c_schmitz Status resolved => closed