| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 03660 | Bug reports | Survey participants (Tokens) | public | 2009-09-07 14:41 | 2009-09-15 12:30 |
| Reporter | Assigned To | c_schmitz | |||
| Priority | normal | Severity | minor | ||
| Status | closed | Resolution | fixed | ||
| Product Version | 1.85+ | ||||
| Fixed in Version | 1.85+ | ||||
| Summary | 03660: Token import accepts invalid characters in the token value | ||||
| Description | When importing a token using a .csv-file invalid characters (for example a dash "-") can be inserted into the token value. This is usually filtered when using the web interface, so entering the token value "ab-cd" in the form will result in the token value "abcd" stored in the tables. In any invitation and reminder emails the incorrect token value (with dashes) will be sent, but when the user clicks on the link or inputs that token, the dashes are filtered away and LimeSurvey cannot find the token without the dashes in the token table (where it contains dashes). Interestingly, it sometimes shows the survey with an error message since it couldn't return token information from that token, instead of the error message that this is an invalid or used token. See the attached screenshot. The token import through csv should probably filter the input just as if one had entered it through the web form. As a side thought, how does LSRC handle when you "push" tokens into a survey? Does it filter the input too? Another side note, does the manual specify what characters are valid as in the token code? I couldn't find anything at a quick glance. | ||||
| Additional Information | In the screenshot the text in the bottom should be "Hej {FIRSTNAME}!" but since no token information was returned it became "Hej !" | ||||
| Tags | No tags attached. | ||||
| Bug heat | 4 | ||||
| Complete LimeSurvey version number (& build) | 7561 | ||||
| I will donate to the project if issue is resolved | |||||
| Browser | |||||
| Database type & version | PostgreSQL 8.3.5 | ||||
| Server OS (if known) | Mac OS X 10.4 | ||||
| Webserver software & version (if known) | Apache/1.3.41 | ||||
| PHP Version | PHP/5.2.4 | ||||
 |
The token should consist only of numbers and letters. I will fix the import and update docs accordingly. |
 |
No other characters at all? Now I use an underscore to separate the first part of the token which is an internal ID from our other database so that it is easier to pair up responses and respondents, from the second part of the token which is a random ID that I generate. It would be really handy for us if some character other than just numbers or letters are allowed, that is why I tried the dash in the first place. Underscores are not as good as dashes since link underlining in HTML makes them less visible, dash would be preferable for readability. |
|
|
A clarification to why we need to be able to pair up responses/respondents, there are two cases where this is interesting for us. First, all the respondents come from a selection from another database that is exported to a CSV. When an invitation email bounces that database must be updated and since you get the original email back when it bounces it is easy to look at the token in the letter and see what record in our database that should be updated. This CAN be solved by me exporting the unique id (that I use for the first part of the token) to an attribute field which I could then use in the invitation email somewhere. But the other case is more troublesome. We often use LimeSurvey, not for surveys, but information gathering due to the extremely handy response tracking of the token system. Each year we hold a convention and the participants use LimeSurvey to tell us what seminars they want to attend to. My collagues that organize the convention can easily see using the statistics the participation on the different seminars. BUT another colleague sometimes need to enter those choices back into our database and up until now it has been easiest to make her the adminstrator and turn on detailed email notification. Then she get an email where the responses AND the token code (which include the id for the person). This could be handled if the detailed email notification for non-anonymous surveys included the token fields for the respondent (including extra attribute fields). I would like this last solution, but that is not mutually exclusive with allowing certain non-alphanumeric characters in the token code (those that do not interfere with URLs, that is no slashes, ampersands, questionmarks, equal signs etc). |
|
|
Underscores and hyphens will be allowed, too. |
