Survey-library: Option cascading for storeOthersAsComment

[SamMousa]

Are you requesting a feature, reporting a bug or asking a question?

Bug in code, or bug in documentation.

What is the current behavior?

Some options are configurable at several levels; for example storeOthersAsComment and questionsOrder can be set at the survey level as well as at the question or page level.
In case of questionsOrder, the behavior is intuitive: (according to docs, haven't verified this)

1. The value at the survey level is a default.
2. The value at the page level allows us to change the default for specific pages.

For boolean variables this is different; if you set storeOthersAsComment to false for the survey, then setting it to true for a specific question does not work.

What is the expected behavior?

I would expect boolean variables to cascade, for example when set to null, or simply missing from the JSON, they should take the value from the parent, in this case the survey.
Instead the survey level variables seem to do a hard override.

How would you reproduce the current behavior (if this is a bug)?

1. Go here: https://embed.plnkr.co/u88GcOmZm7zrVtwYE1HS/
2. Choose "other".
3. Type something in the comment field.
4. Click complete.

Provide the test code and the tested page URL (if applicable)

https://embed.plnkr.co/u88GcOmZm7zrVtwYE1HS/

[andrewtelnov]

@SamMousa Yes, you are right. We should have a default value for question.storeOthersAsComment and it should not be true or false..
We will work on the fix.

Thank you,
Andrew

[SamMousa]

Side note: In my opinion, this specific option (storeOthersAsComment) could be fully removed, in analytics there's hardly ever a reason to use it.

It makes analyzing the data more complex and doesn't offer any benefits.

[andrewtelnov]

@SamMousa Unfortunately, we can't. We made a bad desicion and add it into question level first.
We do our best to make sure all created survey json, even from early version of the project, are still working.
What we can do, and probably, it is the easiest possible solution, is to hide this property from survey creator.

Thank you,
Andrew

[andrewtelnov]

I made this property invisible. However, I feel we still have to fix the bug.

Thank you,
Andrew

[SamMousa]

Definitely agree if you can't remove it then bug has to be fixed.
It can (should?) be marked as deprecated though; that way you at least have the option to remove it in the next version that breaks backwards compatibility.

[andrewtelnov]

@SamMousa The most our surveys are built with help of our Survey Creator. If this property becomes invisible then unlikely somebody would use it.
Absolutely, it worth to mention that it is better to change the behavior on the survey level in property description.

Thank you,
Andrew

[SamMousa]

Well it is reasonable to enable custom behavior on a per question basis (this specific behavior is just never useful)

[andrewtelnov]

@SamMousa I have fixed the bug. New unit test is added.
The fix will be avalable in the next minor update that we will release tomorrow-aftertomorrow.

Thank you,
Andrew