Written by cdouard the 27 Feb 12 at 18:23.

To solve this problem, the send button just have to be on every pages and if they are no compulsory questions remaining this allow to send the questionnaire whatever the page you are on.

OR

Show the All questionnaire index on every pages.
For know, the index grow progressively while you are completing the questionnaire so that you cannot jump to the last question without having seen all the previous questions. If this was possible, people's could go to the last page and send the questionnaire anytime with an error message if they are uncompleted mandatory questions.

To solve this problem, the send button just have to be on every pages and if they are no compulsory questions remaining this allow to send the questionnaire whatever the page you are on. OR Show the All questionnaire index on every pages. For know, the index grow progressively while you are completing the questionnaire so that you cannot jump to the last question without having seen all the previous questions. If this was possible, people's could go to the last page and send the questionnaire anytime with an error message if they are uncompleted mandatory questions.

Written by Vincor67 the 6 Oct 11 at 09:36.

Make an option to block conformation emails

Make an option to block conformation emails

Written by plbt5 the 18 Apr 11 at 13:45.

Add an extra column in Survey Security Management to explicitly authorize a person to access token management for that survey.

Add an extra column in Survey Security Management to explicitly authorize a person to access token management for that survey.

Written by Pat Redmond the 13 Oct 10 at 12:02.

// redirect to secure site
if($_SERVER["HTTPS"] != "on")
header("HTTP/1.1 301 Moved Permanently");
header("Location: https://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"] );
exit();



This could include something along the lines of
if (@secure_login == "required")
...code goes here...


code can be added to admin/admin.php and/or config.php

// redirect to secure site if($_SERVER["HTTPS"] != "on") header("HTTP/1.1 301 Moved Permanently"); header("Location: https://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"] ); exit(); This could include something along the lines of if (@secure_login == "required") ...code goes here... code can be added to admin/admin.php and/or config.php

Written by lovepade the 2 Aug 10 at 12:27.

The codebase seams to be somewhat prepared for this - but not fully. cf. forum topic: http://www.limesurvey.org/support/forums/5-can-i-do-this-with-limesurvey/45939- change-admin-login-page

The codebase seams to be somewhat prepared for this - but not fully. cf. forum topic: http://www.limesurvey.org/support/forums/5-can-i-do-this-with-limesurvey/45939-change-admin-login-page

Written by oddible the 29 Sep 09 at 17:47.

a) Separate the Label Set permission into two permissions: Create and Edit. That way users can create new ones but not mess up other people's existing ones.

b) Allow Label Set definitions that are User Specific or Survey Specific.

c) A button to copy labelsets to simplify the export/import alternative

d) locking a labelset (duplicate?) once a survey uses it for all but that survey's users with labelset rights

My only concern with these is creating too many duplicates of Label Sets.

a) Separate the Label Set permission into two permissions: Create and Edit. That way users can create new ones but not mess up other people's existing ones. b) Allow Label Set definitions that are User Specific or Survey Specific. c) A button to copy labelsets to simplify the export/import alternative d) locking a labelset (duplicate?) once a survey uses it for all but that survey's users with labelset rights My only concern with these is creating too many duplicates of Label Sets.

Written by Kemmotar the 12 Oct 09 at 12:09.

Like oddible I think the best way to solve this problem is to change the way LimeSurvey manage LabelSet permissions.

Separate create/edit roles could be an good idea but I think this could be best used at group level instead on global level. With this solution one user could have edit role in his group but not in others.

- Create scenario: when one user create a labelset he has to set what group the LabelSet is associated with, chosen between groups in which the user is enrolled.

The rights are assigned in group page, adding another button beside the "Delete" one. This new button redirect to an another page in which the right (by now only this only one right, maybe other in the future) has to be set.

An user without administration role will view labelset in the list only if he has labelset edit role for that group.

In the database we have to modify LabelSet table adding two columns: "owner_id" and "ugid", which identify the labelset creator and the group associated to the labelset. Then we should create table lime_user_groups_rights, in which there are three columns: ugid [int], uid [int], edit_label[tinyint]. The latter identifies the editing right.

Like oddible I think the best way to solve this problem is to change the way LimeSurvey manage LabelSet permissions. Separate create/edit roles could be an good idea but I think this could be best used at group level instead on global level. With this solution one user could have edit role in his group but not in others. - Create scenario: when one user create a labelset he has to set what group the LabelSet is associated with, chosen between groups in which the user is enrolled. The rights are assigned in group page, adding another button beside the "Delete" one. This new button redirect to an another page in which the right (by now only this only one right, maybe other in the future) has to be set. An user without administration role will view labelset in the list only if he has labelset edit role for that group. In the database we have to modify LabelSet table adding two columns: "owner_id" and "ugid", which identify the labelset creator and the group associated to the labelset. Then we should create table lime_user_groups_rights, in which there are three columns: ugid [int], uid [int], edit_label[tinyint]. The latter identifies the editing right. Kemmotar