@ollehar : related to SEED ?

Will have a look today.

I need clearer instructions on how to reproduce. This is what I did:

1. Import the attached survey
2. Activate it
3. Create token table with participant
4. Run survey with token (from the admin interface)
5. Write answers, close tab in middle of randomized group
6. Run survey again (tried both with and without newtest=Y in URL)

Can't see any different in group randomization. Also tried with clicking "Resume later".

Using 3.17.5+190604.

I was just able to replicate on the first attempt on the https://demo.limesurvey.org site which looks to be running Version 3.17.3. This issue has existed for as long as I can remember and no one seems to know about it so I think we can safely assume it still exists in 3.17.5.

https://demo.limesurvey.org/index.php?r=admin/tokens/sa/browse/surveyid/959263

1. Token based response persistence must be on.
2. Enter test survey without newtest=Y in url in a private window. Populate survey until halfway through randomized groups.
3. Re-enter the survey with the same token in a new private window.

See attached screenshot for what you will see when experiencing the bug.

If you don't see it on the first time, just immediately close the window and re-enter in a new private window. Sooner or later you will see it.

Now chances are, no one will be entering the survey like above. But its no different than starting a survey on your phone then completing on your desktop later. Its just the easiest way to replicate.

groupRandBug.JPG (71,295 bytes)   

groupRandBug.JPG (71,295 bytes)   

groupRandBugQuestionClasses.JPG (76,662 bytes)   

groupRandBugQuestionClasses.JPG (76,662 bytes)   

@Bigred01 : you can use demo for checking, but it reset all night.
We have a 404: Not Found not foun n,ow for this survey.

Can you send the related lss please ?

I used the one posted above by ollehar. I believe it’s the original one I posted to the forums 10 months ago.

OK :) Great :)

Shuodldn't be using newtest=Y all time?
I think it is mandatory for cleaning old sessions which could have been loaded before.
I know it doesn't match a lot with the scenario because of being private windows, but still, making some initial cleanup never hurts.
Actually, I always try to ad it to the survey urls and I think they are.

The issue is more than that though. When you come in with a clean session after already answering some questions previously, the groups would be re-randomized and it might put an unanswered mandatory group/question before the group it starts you at. It then renders a page with all questions hidden due to relevance error classes and you cannot proceed. My quick hack was to store the group order in a db table using the sid & token as the primary key and use that on entry instead of setting a random order again. I cant remember where in the code i did that now, that was a while ago. That paired with newtest=Y appeared to work but its not a real solution, just a quick hack to get a survey out.

@ollehar : seed must be used to have same radomization for same token ? No ?

I wouldn't rely on the seed to get reproducible numbers.

Besides what it says here (https://www.php.net/manual/en/function.srand.php#16513) you can;t controll that every time that you rturn, the same number of random numbers will be retrieved. You "may" guarantee the sequence is the same. But can you guarantee that there will be no extra random number request in between the sequence?

One of the problems should have got solved by using the newTest parameter on the url.

Having a constant randomness is another issue and is because random sequences are not saved.
Although it is not the expected behaviour on this case, I am not sure it is a bug (sorry, don't want to be rude) but more a design issue that should be tackled.

I will leave @cdorin review what is the suggested next steps.

Thanks!

It does prevent people from completing the survey though. How i found it in the first place was when we started to receive a series of complaint emails. Group randomization is essentially useless when you have token based response persistence on and someone doesn't complete the survey in a single sitting. There is a very good chance the next time they enter they will encounter this.

I understand you mean.