Written by roB2009 the 2 Nov 09 at 15:58.

Written by seancarlos the 20 Jun 11 at 07:48.

Need to add unsubscribe email address and URL fields to UI + data structure. Consider validating for well formed email / urls. If one or both are present, add List-Unsubscribe header to email messages.

This probably needs to be done as part of global settings with the option to override it at the survey level, including suppressing global settings if present.

Need to add unsubscribe email address and URL fields to UI + data structure. Consider validating for well formed email / urls. If one or both are present, add List-Unsubscribe header to email messages. This probably needs to be done as part of global settings with the option to override it at the survey level, including suppressing global settings if present.

Written by JEfromCanada the 30 Nov 11 at 07:47.

I propose that one or more of the commonly used URL shortening services be contacted to determine if they have an API that would allow Lime Survey (or Lime Service) to call the URL shortening service with the value of SURVEYURL and return with a value which would be stored in SHORTSURVEYURL.

The user would have the option of using the SHORTSURVEYURL in email templates to guarantee that survey urls generated by Lime Survey would be shorter than the "typical" line size of an email program.

After initially posting this idea, I came across an existing API for the tinyurl service. Rather than repeating the code here, I will reference the page where it can be found...

http://www.richardcastera.com/blog/creating-a-tinyurl-with-tinyurl-api

The fact that this API already exists means that Lime Survey does not need to search for a URL shortening API!

I propose that one or more of the commonly used URL shortening services be contacted to determine if they have an API that would allow Lime Survey (or Lime Service) to call the URL shortening service with the value of SURVEYURL and return with a value which would be stored in SHORTSURVEYURL. The user would have the option of using the SHORTSURVEYURL in email templates to guarantee that survey urls generated by Lime Survey would be shorter than the "typical" line size of an email program. After initially posting this idea, I came across an existing API for the tinyurl service. Rather than repeating the code here, I will reference the page where it can be found... http://www.richardcastera.com/blog/creating-a-tinyurl-with-tinyurl-api The fact that this API already exists means that Lime Survey does not need to search for a URL shortening API!

Written by lovepade the 8 Nov 11 at 15:27.

In my case an autofilter solution like what is implemented in the typical spreadsheet application whould suffice. (as long as it is implemented on all fields).

But more general speaking the ability to apply a search criteria to all fiels would be very welcome.

In my case an autofilter solution like what is implemented in the typical spreadsheet application whould suffice. (as long as it is implemented on all fields). But more general speaking the ability to apply a search criteria to all fiels would be very welcome.

Written by vision the 8 Feb 12 at 09:48.

Please add the option to receive an admin notification when someone completes a public registration.

Please add the option to receive an admin notification when someone completes a public registration.

Written by tacman1123 the 5 Feb 12 at 13:06.

When tokens are defined, instead of merely asking "how many", it would need to change to a list format that asked the field names (and types, but that's a different issue!)

When tokens are defined, instead of merely asking "how many", it would need to change to a list format that asked the field names (and types, but that's a different issue!)

Written by Oli_71 the 27 Jul 10 at 17:10.

?

?

Written by lovepade the 16 Sep 10 at 18:16.

Embeding a unique picture in each email could solve the problem. In the token table, an extra column "read" could then indicate wether the person had open the email, and thus downloaded the token.jpg file from the server.

There should also be a view where "read" percentage for each survey gets listed.

gmail and other email providers block this kind of picture by default, so the solution is not bullet proof. But I think it's the best approach.

The approach is also sufficient, since we are mostly interested in seeing if the numbers all of sudden changes. I.e. it is not importen if 90 or 85% opens the email - but if the numbers drop to 50% we have a problem.

This is especially true in larger organisations, like universities wich sometimes have very strict filtering.

Embeding a unique picture in each email could solve the problem. In the token table, an extra column "read" could then indicate wether the person had open the email, and thus downloaded the token.jpg file from the server. There should also be a view where "read" percentage for each survey gets listed. gmail and other email providers block this kind of picture by default, so the solution is not bullet proof. But I think it's the best approach. The approach is also sufficient, since we are mostly interested in seeing if the numbers all of sudden changes. I.e. it is not importen if 90 or 85% opens the email - but if the numbers drop to 50% we have a problem. This is especially true in larger organisations, like universities wich sometimes have very strict filtering.

Written by eckes the 14 Nov 09 at 21:19.

In order to avoid that a malicious limesurvey installation can give the same vote-code to multiple users it makes sense to generate the vote-code with voter specific data and a random secret.

I am aware that not all users can verify it, but there is still a good changce to spot problems for interested voters.


This would look like this:

Your vote will be documented in the public list like this:

VoteId | Votes
8edb010327bffc70dc2c | 0001: yes 0002: no

The VoteId above is generated personally for you. You can verify this, because we used the following method to generate it:

cut20(sha256("berndeckenfels 1446hhhfdgdfg545"))

(I.e. using your token, appending a random string, calculating the SHA-256 checksum and using the first 20 characters of the hex representation.

In order to avoid that a malicious limesurvey installation can give the same vote-code to multiple users it makes sense to generate the vote-code with voter specific data and a random secret. I am aware that not all users can verify it, but there is still a good changce to spot problems for interested voters. This would look like this: Your vote will be documented in the public list like this: VoteId | Votes 8edb010327bffc70dc2c | 0001: yes 0002: no The VoteId above is generated personally for you. You can verify this, because we used the following method to generate it: cut20(sha256("berndeckenfels 1446hhhfdgdfg545")) (I.e. using your token, appending a random string, calculating the SHA-256 checksum and using the first 20 characters of the hex representation. On Unix you can do: echo "berndeckenfels 1446hhhfdgdfg545" | sha256 | cut -b1-20 Now: voter can check if the published sheet contains vote voter is shure LimeSurvey cant assign the code to two votes voter is shure that the code which is published is not related to the token and nobody (besides limesurvey who generated the random number and stored the code in database) can associate it with the user. (In my example the token is user name, but of course it would be a random string in most cases).