Welcome to the LimeSurvey Community Forum

OK,
Still : How you disable access to authenticatoion via DB password ?

Quick (and dirty) way :
1. remove/rename : github.com/LimeSurvey/LimeSurvey/blob/ma...n/Authentication.php
2. remove/rename github.com/LimeSurvey/LimeSurvey/blob/ma...in/RemoteControl.php

Best way : send a 401 with your nginx/apache config according to URL (depend of your server: can not answer here).

If you want explicit N/A selections, you can do this...

1) Add a multiple-choice question after the slider question with the same sub-questions and codes.

2) In the slider question, set array filter exclusion to that new question code.

3) In the slider question, set array filter style to "Disabled".

4) Add this little script to the source of the slider question. It will move the check-boxes into that question.




Sample survey attached:  

tpartner wrote:

Yeah, the bootstrap-multiselect is interesting but it looks like a little work may be required for use in 6.x - davidstutz.github.io/bootstrap-multiselect/#migration .
 

Maybe need to add gitlab.com/SondagesPro/coreAndTools/Boot...ey.js?ref_type=heads

in the question theme directly too.

Things are not totally different in LS6 compared to LS5 or LS3. The concepts are usually the same, there might be some minor details (especially when Javascript/CSS) is involved and the GUI of the back end might look slightly different. The rest is usually the same.

However, I am not 100% sure what your survey will look like, what types of questions you are using, etc.

But I can tell you already one thing:

It's also important that each question in each part of the survey is answered an even amount of times, so that one question does not have more responses recorded than another.

This probably won't fly, at least not with a decent amount of adaption. If you randomize, you use "chance". The bigger the sample, the closer the probability of an even distribution. But it usually just gets close, it never is 100% equal. So, then you would have to get rid of "Chance" or at least help "chance" by creating something like a bucket least filled concept. To be honest, I think this is overkill. As long as the questions have been shown/answered fairly evenly, it should be fine. If you analyze something and one question has been shown 90 times and the other one 110 times, there should be no major difference to 100/100.

But to be able to help you, it would be great if you could provide is with a little mockup of your survey. It doesn't need to be complete and it doesn't need to show the actual questions, but it would help to understand better what you are trying to setup.

If we ignore the fact that you want to guarantee an absolute even distribution of each question (the issues of which I have explained above), this is actually not overly complicated, if I understood you right.

This would involve to create 6 question groups, 2 for each part. From now on, I will focus on the explanation for 1 part only, as for the others it is just the same. It doesn't matter if you have just 1 part or 10.000, things will follow the same idea.

So now you have 2 question groups, lets call them "names1" and "names2".

In the group "names1" you will put 11 questions for the names, in "names2" you will put the other 22 questions. Each of these 33 questions will receive the same code in the "randomization group name" field of each question.

What will this do? It will shuffle the 33 questions randomly over the 33 question positions within the 2 question groups. Now if this works fine, you just hide the group "names2" and there will always only be shown the question group "names1" with 11 random questions out of the pool of 33 questions.

You'll do the same for the 2 other parts (of course depending on the number of questions you have and what to show in each part).

So far, so good. Now you have 3 parts and in each part you will see a random selection of the whole pool of questions for this specific part.

What is missing? The randomization of the parts. That is easy as well. You'll give each question group that is shown (e.g. "names1", "behaviors1" and "graphs1") the same code in the field "randomization group name" in the respective question groups, and voila, now Limesurvey will show your question groups (or "parts" how you call them) in a random order.

Now the issue is that we depend on chance, and as we have seen before, depending on the sample size, this will most probably lead to a "relatively" even distribution of each question, but chances are very little that the distribution will be exactly even.

How to solve this?
Option 1. Get rid of this "illusional" requirement
Option 2. Manually adapt during the field time. You can have a look into the statistics and see how often a specific question has been seen / answered. If one is too far ahead, just give it a "0" in the "relevance equation"/condition field and it won't show up again. If you take out the zero, it will be in the shuffle again.
Option 3. create a complicated bucket least filled system based on the statistics functions from within Limesurvey. But this can be quite complicated with the number of options you have.
Option 4. Create fixed groups of questions for each part and show them randomly. E.g. create 3 groups per part and put 11 questions fixed into each of these question groups. This allows you to easier control the distribution. within the quesiton group you can still randomize the questions in terms of order. However, it will of course not be a perfect randomization either, as there are always 11 questions together.

I am sure, Joffm will have some ideas too.