Hi everyone,
I am still trying to link LimeSurvey to our Sona Systems subject pool (see www.sona-systems.com/help/limesurvey.aspx ). The core idea is here to send participants from Sona to LimeSurvey with the survey code of the experiment in the url: e.g. limesurvey.de/index.php/284885?lang=de&id=%SURVEY_CODE% After finishing the survey on LimeSurvey they are then send back to Sona via the end URL, which passes the survey code (via {PASSTHRU:id}) back again. This should mark them as participated in the subject pool.

If I run LimeSurvey in open access mode, this works just fine. However, as soon as I try to use the close-access mode only receive the following error message when send back to Sona System: "Invalid survey_code". According to Sona this indicates that either the survey code is blank, or was not specified at all.

Something seems to be happening in the background here that apparently prevents the id/survey code from being passed through correctly in closed-access mode. My current guess would be that the parameter I am saving the id in is not accessible in the beginning when in closed-access mode. But I couldn't find anything in the documentation or the forum that helped me to understand what really is amiss here. I would greatly appreciate any kind of insight into what is going on here and whether this can be solved in some way.

P.S. The LimeSurvey manual advises to disable the welcome screen to prevent the id from not being loaded. For me when in open-access mode the panel integration works no matter whether the welcome screen is activated or not.

LimeSurvey version?

Try adding a hidden short-text question with code "id". That will be loaded via the URL parameter. Then you can ignore the PASSTHRU "feature" and simply use {id} in the end URL.

NOTE: To test, un-hide the short-text question and disable auto redirect to the end URL. This way you will see whether the question is loaded and see the URL in the end message.

Thank you! I will test this later and post here whether it worked out.

LimeSurvey version is 3.22 .

Please do not double post!
forums.limesurvey.org/forum/installation...d-closed-access-mode

Sorry about the double post. I first posted in the wrong category. I tired to delete that post, but I guess that didn't work out.

Thanks again for your answers! I added the hidden question linked to the URL parameter as both of your described. Again that worked perfectly for open access-mode: The id was depicted in the question (if it was displayed) and appeared in the end URL.

In closed-access mode however, the id is not put into the hidden question and the end URL at all.

Some observations from testing:

• The id is (of course) present in the URL of the very first screen when arriving from Sona Systems in either mode.
• Whether or not the welcome screen is displayed doesn't matter in open-access mode, even if the id is not shown in the URL any more when the corresponding hidden question is loaded.

To me it still seems that in closed-access mode the id is simply lost after arriving to the initial page asking about the access key. Or is there something I am again missing here?

I think you are not giving us the whole picture.

When you say "closed mode", I assume you are talking about tokens (not anonymous mode)?

Are the tokens included in the URL? Because if respondents need to put the token manually, then I don't think you can pass anything via the URL.

However, when you already use tokens, why not include the ID into the token table already and use it from there???

[strike]Also, we do not know which LS version you are using.[/strike]

To me it still seems that in closed-access mode the id is simply lost after arriving to the initial page asking about the access key.

Can you get the panel provider to append the token to the survey URL? This is a very common practice as it skips the token-input screen.

holch wrote: Also, we do not know which LS version you are using.

Already stated. LimeSurvey version 3.22.

This issue around not capturing URL parameter when a token entry screen is used, is not new.
We have run into that issue years before.

I recommend to open a bugreport first.