View Issue Details

This bug affects 1 person(s).
 6
IDProjectCategoryView StatusLast Update
14401Bug reportsSurvey participants (Tokens)public2019-05-29 16:39
ReporterMazi Assigned Todominikvitt 
PrioritynoneSeverityminor 
Status closedResolutionunable to reproduce 
Product Version3.15.x 
Target Version3.16.xFixed in Version3.17.x 
Summary14401: If options for "token based answer persistance" and "Allow multiple responses..." are enabled, "uses left" is not decreased
Description

If at a closed survey the options for "token based answer persistance" and "Allow multiple responses or update responses with one token:" are enabled, the uses left value doesn't get decreased on submit. I think this was the case at previous versions like 2.6 LTS. It can cause the following problem: If a user now changes those two settings by switching them off, all participants can participate once more - since uses left is 1 on survey start - so we end up with 2 data sets for each participant.

Steps To Reproduce
  1. Use a non-anonymous survey with "token based answer persistance" and "Allow multiple responses..." enabled.
  2. Add a test user.
  3. Add a data set for that user.
  4. Change those two settings by switching them off.
  5. Take the survey with your test user again and submit another response.
  6. You end up with two response data sets for the same user though it is a closed survey with "uses left" being set to 1 as default value.
TagsNo tags attached.
Attached Files
Bug heat6
Complete LimeSurvey version number (& build)3.15.5+181115
I will donate to the project if issue is resolvedNo
BrowserChrome
Database type & versionMySQL 5
Server OS (if known)Ubuntu 14 TLS
Webserver software & version (if known)Apache 2
PHP Version7.0

Users monitoring this issue

There are no users monitoring this issue.

Activities

DenisChenu

DenisChenu

2019-01-07 14:59

developer   ~50123

I think « update responses with one token» (with «token based answer persistance») don't use useleft

https://github.com/LimeSurvey/LimeSurvey/blob/05f0bf840c58bd4f3526527706eb8cfc8a00e7b2/application/controllers/survey/index.php#L511

I think in 2.6lts : use left was decremented in all situation.

c_schmitz

c_schmitz

2019-05-23 14:41

administrator   ~52077

I agree that the old behavior needs to be restored.

dominikvitt

dominikvitt

2019-05-23 18:23

developer   ~52096

Unable to reproduce this issue using the latest GitHub version on my local machine.
Steps I took:

  • created survey, activated it and created 1 user with token
  • enabled above mentioned survey options
  • run the survey until finished
  • opened token list again: Uses left is set to 0, if I open survey using link with token, message is shown: "This invitation has already been used."
  • disabled survey options (but it doesn't matter any more, because counter is already on 0)
DenisChenu

DenisChenu

2019-05-24 00:27

developer   ~52101

Last edited: 2019-05-24 00:27

opened token list again: Uses left is set to 0, if I open survey using link with token, message is shown: "This invitation has already been used."

Then you don't set the good options, because with the good options you can open survey (same survey) again and again.

I use a lot this system for data management by LimeSurvey :)

PS : still : the behaviour is now same than 2.6lts : Use left is decremented each time survey is submitted (no quota inside survey)

dominikvitt

dominikvitt

2019-05-24 13:25

developer   ~52106

I just tested it again and I'm having a different result than yesterday, although I'm sure I had correct options set.

Test:
Survey settings are enabled.
Now I'm having "Uses left" set to 0 after the first run and after the second run it get decreased to -1.
For each following run, counter always stays on -1.
I can run survey every time without restrictions.
I had only one data set the whole time and it's data was remembered between each run.
There wasn't a second data set for used token.

When I disabled survey options at the end of my testing, survey can't be run any more because of negative counter (-1).

DenisChenu

DenisChenu

2019-05-24 13:32

developer   ~52107

Your description is exactly the desired behaviour :)

c_schmitz

c_schmitz

2019-05-29 16:39

administrator   ~52234

Version 3.17.4+190529 released

Issue History

Date Modified Username Field Change
2019-01-07 10:45 Mazi New Issue
2019-01-07 10:45 Mazi Status new => assigned
2019-01-07 10:45 Mazi Assigned To => c_schmitz
2019-01-07 14:59 DenisChenu Note Added: 50123
2019-05-23 14:40 c_schmitz Assigned To c_schmitz => dominikvitt
2019-05-23 14:41 c_schmitz Note Added: 52077
2019-05-23 18:23 dominikvitt Status assigned => resolved
2019-05-23 18:23 dominikvitt Resolution open => unable to reproduce
2019-05-23 18:23 dominikvitt Fixed in Version => 3.17.x
2019-05-23 18:23 dominikvitt Note Added: 52096
2019-05-24 00:27 DenisChenu File Added: Capture d’écran du 2019-05-24 00-26-20.png
2019-05-24 00:27 DenisChenu Note Added: 52101
2019-05-24 00:27 DenisChenu Note Edited: 52101
2019-05-24 13:25 dominikvitt Note Added: 52106
2019-05-24 13:32 DenisChenu Note Added: 52107
2019-05-29 16:39 c_schmitz Note Added: 52234
2019-05-29 16:39 c_schmitz Status resolved => closed