View Issue Details

This bug affects 1 person(s).
 6
IDProjectCategoryView StatusLast Update
15547Bug reportsExpression Managerpublic2019-11-15 08:27
ReporterDenisChenu Assigned To 
PrioritynoneSeverityminor 
Status newResolutionopen 
Product Version3.19.3 
Summary15547: Invalid error count on Survey Logic file for subquestion relevance
Description

When there are subquestion relevance : error count is more higher than needed

Steps To Reproduce

Create a question with 3 sub questions
Add an error in 1st subq relevance : Question logic file shown 4 error
Add a subquestion : Question logic file shown 5 error

Additional Information

Issue in SurveyLogicFile function :
SubQ relevance use ProcessBooleanExpression, and this function dodn't reset errors count
Subq test use ProcessString and this function reset errors only if there are { } inside text
Then errors count (and aErrors) are not resetted …

TagsNo tags attached.
Attached Files
Bug heat6
Complete LimeSurvey version number (& build)3.19.3 github
I will donate to the project if issue is resolvedNo
Browsernot relevant ?
Database type & versionnot relevant?
Server OS (if known)not relevant ?
Webserver software & version (if known)not relevant ?
PHP Versionnot relevant ?

Relationships

related to 15545 acknowledged Bug reports Survey logic file show valid question even if not valid 
related to 15532 closedDenisChenu Feature requests Show warnings when implicit alphabetical compare is used in expressions 

Users monitoring this issue

There are no users monitoring this issue.

Activities

DenisChenu

DenisChenu

2019-11-08 08:09

developer   ~54480

Potential fix ( with related) : add a ExpressionManager::SurveyLogicInfo with errors (and warnings) , used ONLY for SurveyLogicFile …

ExpressionManager::HasErrors are used in some relevance system (show question if there are error in relevance) if i remind (unsure).

jelo

jelo

2019-11-08 10:42

partner   ~54481

I'm more and more confused with labeling of "Product Version".
3.19.4 is not 3.19.3git nor it is 3.19.3.

So the current label system is not able to reflect the developement status in between.
Is choosing the next version number (3.19.3git = 3.19.4) a consistent rule or will I find 3.19.3git=3.19.3 in Mantis too?

cdorin

cdorin

2019-11-14 22:00

reporter   ~54603

If you use the git version, mention the last commit merged - that would be the ideal case scenario. But in this case, we know Denis is running (I assume) the latest git version :)

DenisChenu

DenisChenu

2019-11-15 08:27

developer   ~54604

:)

Yes always before reporting. But @jelo are right : here it's a 3.19.3 git, and not a 3.19.4 :).

But if it happen in 3.19.3 git, it happen in 3.19.3 (else i put the build number to the link brokin something at github)

Issue History

Date Modified Username Field Change
2019-11-08 08:04 DenisChenu New Issue
2019-11-08 08:04 DenisChenu File Added: Capture d’écran du 2019-11-08 08-03-51.png
2019-11-08 08:04 DenisChenu File Added: limesurvey_survey_issueErrorCount.lss
2019-11-08 08:04 DenisChenu Relationship added related to 15545
2019-11-08 08:05 DenisChenu Relationship added related to 15532
2019-11-08 08:09 DenisChenu Note Added: 54480
2019-11-08 10:42 jelo Note Added: 54481
2019-11-08 10:50 DenisChenu Product Version 3.19.4 => 3.19.3
2019-11-14 22:00 cdorin Note Added: 54603
2019-11-15 08:27 DenisChenu Note Added: 54604