From LimeSurvey Manual
Save and resume later functionality has been in LS for a long time.
This document serves to re-analyze the requirements and brainstorm implementation improvements.
Current table design
Currently a special table is used to store data related to saving and resuming. This table contains the following columns:
- - scid
- - sid
- - srid
- - identifier
- - access_code
- - ip
- - saved_thisstep
- - status
- - saved_date
- - refurl
This is a lot of data, and comes with a lot of responsibility with respect to cleaning up the correct rows at some point.
Proposed table design
Since LS3 uses a GUID as id we have a simple option of implementing this with a separate table:
This also allows loose coupling with other LS components; since we can just craft a URL that the user can use to continue the survey using his GUID, all we need to do is create a cotnroller that verifies username / password and then posts the found GUID to the right controller / action.
all other information is already in the response table and there is no need to duplicate it.
What are the actual functional requirements for this feature?
- ? The user must be able to continue from another browser session (same / other pc doesn't matter)
- ? The user must receive a link at his emailaddress
- ? The user must be able to set a username + password to continue later without email.
- ? The response must (not) be shown as partial response in the results page.
Implementation details for LS3
The response ID is contained in the URL, so the question is if we really need to save any state here. Emailing the user a link to the URL with the response id in it will allow him / her to continue at any point.
If we want to support username / password re-entry we could add 1 or 2 columns to the response table; in any case there seems to be a lot of information in the saved_control table.
- For future versions a feature to let a Limesurvey admin re-enter any existing non-complete response will be helpful.
- @Emailing the user a link to the URL with the response id in it will allow him / her to continue at any point
- When using tokens we can simply add the token to the URL
- Simply emailing a link with e.g. the data set ID is a security issue (unless the IDs change to hash values) so we should always use a username/PW for such a re-entry. (Sam: ids in LS3 are guids so no issue there) (Shnoulle : security risk : mail error/mail for different user/ User don't have email)
- User/Pass : A user can remind a user/pass but not a response_id : needed
- User/pass : BUT can be done in a plugin
- Actual step : really needed : BUT can be better updated : actually we save "step" but not the "maxstep". Adding maxstep in the response table fix this issue (see https://www.limesurvey.org/en/extensions/77-fixmaxstep). Can be done in plugin too (with a "plugin table").
- Send the unique link id : Marcel have rigth here : Error in email and ID is send elsewhere + Bad SMTP server (no SSL/TLS) : id is every where.
- For token based survey : we already use token to save survey : token answer persistence.
- PS : i like to use mantis for this purpose ... look at http://bugs.limesurvey.org/view.php?id=9557 http://bugs.limesurvey.org/view.php?id=9522 etc ....
- After reading Carsten , really think we can move it to an external core plugin (can be deactivated), we need a way to add it in "template" with the plugin somewhere. Maybe plugin event for navigator button ?
- Since email address can break anonymity we should never save it with anonymized surveys - only use it to send the password reminder once they save it.
- Keeping it in a separate table makes sense since the fields are rarely used and if merged with the main response table would further reduce the already tight column count
Remember that the SaveResume feature is used in three different scenarios:
- Open surveys
- Closed non-anonymous survey
- with token persistence (in this case the table is never used)
- without token persistence
- Closed anonymous survey
I think the main problem with this feature is that we don't see it from the administrator perspective - the available options are confusing and alot of times the implications are not clear. The problem is not really the table but the admin interface usability.