Apologies if this posting is in the wrong location.

Here at the University of Guelph we're using LimeSurvey for online elections and other voting applications. We need to ensure the results are anonymous, but also need to be able to set conditions on questions based on the "additional attributes" in the token table (e.g. attribute_1, attribute_2, etc). With 1.91 our understanding is that the survey cannot be anonymous if you need to access these "additional attributes" for setting conditions on questions.

Is this capability (survey remains anonymous but there is access to the token table's additional attributes for setting conditions) something that can be added in a near future release? Guelph would gladly contribute funding if this would help get this feature in place.

Thanks in advance for any thoughts or suggestions,

Peter McCaskell

To put it in a nutshell: If a survey is set to be non anonymous, there is no connection between the token data and the survey data so you can't use the token attributes.

For doing so, one would need a layer in between to not create a token columns at the results table but have access to the attribute data. This would mean some bigger changes at the survey engine and it would take some time.

We are planning to release Limesurvey 2.0 based on a completely overworked code base in the next weeks so if you plan to implement this, your work should be based on that version.

What you could try to do is pass the attributes to the questionnaire via the URL. But then, they are written in the URL...

Many thanks for the replies - very much appreciated !
Peter

You're welcome!

If our hints have been helpful and you enjoy limesurvey please consider a donation to the team .
We do all this in our free time and you don't have to pay a penny for this software.

Without your help we can't keep this project alive.

Mazi wrote: ANd then survey CAN NOT be set to anonymous.

For example, i use attribute_1 to put the identity card number, and fill a question of the survey ....

It's a major security risk. Official LS version don't have to do this.

Shnoulle is totally right. As soon as any attribute from the token table can be passed on to the survey it can not be called anonymous anymore. I guess Peter only wants to pass on variables like gender, etc, but as Shnoulle showed already, you could always pass on private data and while Limesurvey would say the survey is anonymous, it is actually not. So we really need to avoid this in LS.

Thanks for the additional comments, and I fully agree that we need to avoid this when using Limesurvey.

Our dilemma is that we currently use Limesurvey for a wide range of online voting applications, and it works really well except for the following scenario that I think might be relevant to other folks in the LS community as well as to us here at the University of Guelph:

We use a multi-question survey to let our students vote for candidates for various positions in our student government (President, Treasurer, Medical Studies Program representative, Engineering Studies Program representative, Agricultural Studies Program representative, etc.). The survey contains all the possible "ballots" covering all the positions up for election. However students can only vote for the positions appropriate for their academic program i.e. we don't want students in the Medical Studies Program voting on the Engineering Studies representative for example. We use the attribute_1 ... attribute_n fields of the token table to determine what ballots any given student is eligible to vote on as it's easy for us to get this information into the token table form our student information system.

We "hide" the questions a particular student should not see, using the attribute_1 ... attribute_n fields in the token table to make the conditions. Again, this works really well, but to get at these attributes the survey cannot be anonymous, so the student's identifying information is stored in the database along with how they voted on the various questions. This is a problem for us as the voting is then not anonymous.

It would be great if LS 2 might provide a workaround for this so one can access the token table attributes for making show/no-show conditions, but still keep the results anonymous.

Thanks for your interest in this discussion,
Peter

Hi Peter, I understand your general dilemma, but as soon as you are available to connect attributes from the token table with the results (and at the end of the day that is what you are doing by passing this information on to the survey) the survey can NOT be "anonymous" by the standards that you require. I think this is a general problem and probably can't be resolved technically.

I personally would consider the survey still annonymous, as long as you do not connect the token table with the results table during the analysis. However, some folks are more strikt and the pure possibility to do so already makes it not anonymous. I guess for voting this is an important concern, in market research not so much. We often need to have the chance to connect name with a survey anyway, and even if it is just for providing the incentives.

Now my idea was if it is possible to pass on the variables via the URL when the survey is anonymous. This would probably solve the problem. I am not sure if this is possible.

Thanks so much for your additional input to this discussion - really appreciated !

Passing the "values used for conditions" via the URL does indeed get us the full anonymity we need. Now I just need to put some thought into how to ensure the voter can't tamper with the URL parameters so they get to vote on ballots (i.e. "questions") they shouldn't have access to. I don't yet know enough about the upcoming Expression Manager (EM) toolset but, in addition to the wide range of great things EM will let us do in general, it may very well be able to help tamper-proof the URL parameters approach - I'll certainly be looking into EM to see if it can help in this capacity.

Thanks again for all your interest and assistance !

Peter