LimeSurvey bugs and feature requests - Issues

20778: Configurable default values for notification fields (admin, adminemail, bounce_email) at survey creation

Tue, 20 Oct 2026 09:57:51 +0200

Currently, when a new survey is created, the three notification fields below inherit their
values from the parent survey group (or from the global defaults). There is no built-in way
to define what those defaults should be, nor to auto-fill the bounce address from the survey
owner's email.

We would like to be able to set, per instance (or per survey group), the following defaults
applied automatically to every newly created survey:

1. "Administrator" (admin) -> Inherit: OFF, field left empty
2. "Administrator email" (adminemail) -> Inherit: OFF, field left empty
3. "Bounce email" (bounce_email) -> auto-filled with the survey owner's email address
(Inherit: OFF)

Motivation / Use case
---------------------
We manage many surveys, each owned by a different person. We want bounce/delivery-error
notifications to go directly to the survey owner, without having to manually edit the
"Notification & data management" tab of every single survey after creation. Today this is a
repetitive, error-prone manual step: if an administrator forgets to switch "Inherit" off and
to set the correct bounce address, error notifications silently go to the wrong recipient (or
to the global admin), which can mean lost feedback and undetected invalid addresses.

Desired behaviour
-----------------
At survey creation (UI and RemoteControl2 API), the three fields above should be initialized
from a configurable default policy rather than blindly inheriting:

- a global / per-group setting defining the default state of inheritan, inheritema,
inheritbnc and the default content of admin / adminemail / bounce_email;
- a special token/placeholder (e.g. {owner_email}) usable as the default for bounce_email,
resolved to the email of the user who owns the survey (users.email of owner_id).

Proposed implementation (suggestions, not prescriptive)
-------------------------------------------------------
- Add new global settings in the "Global survey settings" panel for the three fields.
- When a survey is created, apply these defaults instead of pure group inheritance.
- Support a {owner_email} placeholder for bounce_email, resolved at save time from the
owner's account.

20777: Attempting to duplicate a question group on a active survey causes an error

Mon, 19 Oct 2026 17:16:59 +0200

20776: Survey question group settings are untranslated

Mon, 19 Oct 2026 13:27:59 +0200

20774: Survey saving error message is untranslated

Mon, 19 Oct 2026 08:48:37 +0200

Fix should be as simple as wrapping the string in t() on editor/src/components/wrappers/SurveyLogicProvider.js:197.

20773: React Date Range Picker is untranslated

Fri, 16 Oct 2026 15:52:50 +0200

The react-date-range library does have a locale property for the picker component, I imagine this could be used: https://www.npmjs.com/package/react-date-range. The package also appears to be unmaintained.. perhaps there is a better alternative?

20772: CLI updatedb does not clear the web schema cache: admin pages show 500 DB errors for up to 1 hour after the update

Fri, 16 Oct 2026 13:23:08 +0200

After a database update with the CLI (`php application/commands/console.php updatedb`), the web side can keep using the OLD table schema from its cache for up to 1 hour. During this time, admin pages show "500 Database error".

This is a minor issue: it fixes itself after the cache expires, and deleting the cache fixes it at once. But right after an update, it looks like the update has failed, and an admin may restore the DB or run the update again.

I found this while testing for 20771 (it is the second "related problem" at the end of that report).

**Cause**
- `application/commands/console.php` defines `YII_DEBUG` as true. So in the CLI, the cache component is `CDummyCache` (`application/config/internal.php`, around line 192).
- At the end of the update, `$oDB->schema->refresh()` and `Yii::app()->cache->flush()` (in `updatedb_helper.php`) only clear this dummy cache. The web uses `CFileCache` in `tmp/runtime/cache`, and these files are not touched.
- The web caches the table schema for 3600 seconds (`schemaCachingDuration`).
- If a web page is opened while the DB is still old (for example the "database update is already in progress" page), the old schema is written to the web cache. After the CLI update ends, the web still uses it.

**What we saw (6.17.19 -> 7.3.0)**
- On `/index.php/dashboard/view`: `CException: Property "Survey.preselectnoanswer" is not defined` (`SurveysGroupsettings.php`)
- Right after login: `CDbException: Unknown column 'survey.nokeyboard'`
- The cache file for the `lime_surveys` schema still had `nokeyboard` (removed by `Update_702`) and did not have `preselectnoanswer` (added by `Update_712`). Its time matched the moment we opened the "update in progress" page.
- With `debug` = 1 (no cache), the error went away. With `debug` = 0, it came back. After deleting `tmp/runtime/cache/*`, it was fixed at once.
- The same code is still in 7.5.1 and master (`console.php`, `internal.php`, `updatedb_helper.php`). `updatedb_helper.php` even has the comment "Try to clear tmp/runtime (database cache files)" before `Yii::app()->cache->flush()`, but in the CLI this only flushes `CDummyCache`.

**Workaround**
Delete `tmp/runtime/cache/*` manually after a CLI update. We now do this in our update procedure.

**Idea for a fix**
After a successful CLI update, also clear the web cache (`tmp/runtime/cache`), for example by flushing a `CFileCache` instance for that directory.

**Environment**
LimeSurvey 7.3.0 (build 260922) / MariaDB 10.5.26 / PHP 8.2.33 / Linux (shared hosting)

20771: Update_700 re-run irreversibly destroys timing data and ranking subquestions; migrated 6.x surveys then fail with 500 DB error

Fri, 16 Oct 2026 09:30:51 +0200

When Update_700 (6.x -> 7.x migration, DBVersion 651 -> 700) runs on a database where some or all tables are already migrated, data is deleted without any error.

What is lost:
1. Timing data. Already migrated tables "lime_timings_" and "lime_old_timings__" are replaced by EMPTY tables "lime_" and "lime_old__". The original rows are dropped.
2. Ranking questions. All subquestions of ranking (type R) questions are deleted and cannot be rebuilt (subquestions 3 -> 0; the answers were already removed by the first run).
Response tables (lime_responses_) are not affected.

The damage cannot be undone inside LimeSurvey: the original tables are dropped and no copy is kept, so the only way back is a backup taken before the update.

Impact on a real site: our staging server (updated from 6.x to 7.x on 2026-06-20, now 7.3.0) lost timing and ranking data in the same way. Since then, opening any survey that was created in 6.x as a respondent always shows:
"500: Internal Server Error - Database error!"
So the surveys inherited from 6.x can no longer be used. (This error stays for months, so it is not the 1-hour schema cache problem described at the end.)

This can happen in real life, not only in a test:
(a) An update stops in the middle (web timeout, killed process) and the admin starts the update again. Depending on where it stopped, the second run ends with "Database has been successfully upgraded to version 717" and NO error, but the tables that were migrated before the stop are now empty. The admin does not notice.
(b) DBVersion is below 700 again after a finished migration (for example after a partial DB restore).

Cause (application/helpers/update/updates/Update_700.php, line numbers from 7.5.1 / master; the same code is in 7.3.0 and 7.4.0):
- getTimingScript() (line ~1199) finds timing tables with TABLE_NAME LIKE '%timings%'. This also matches the NEW name "lime_timings_". REPLACE() then makes the new name "lime_".
- These tables are not "handled" by the column conversion, so the loop at lines ~2310-2316 runs CREATE (empty copy with the new name) and then DROP of the original table. No data is copied.
- up() (line ~2015) first runs deleteRankingSubquestions() (line ~1376), which deletes ALL subquestions of ranking questions without any condition. The answers that are needed to rebuild them were already deleted at the end of the first run.
- Response tables are found with 'survey_[0-9]*', so already migrated "responses_*" tables are skipped. This is why only timings (and ranking subquestions) are lost.

Expected result:
Update_700 should skip tables that are already migrated, or stop with a clear error. It should never drop a table that has rows without copying them. Ranking subquestions should only be deleted when there are answers to rebuild them from.

Actual result:
Timing data and ranking subquestions are deleted silently. In case (a) there is no error message at all.

Ideas for a fix:
- getTimingScript(): match only the old name pattern (for example "survey\_%\_timings"), not "%timings%".
- Before CREATE/DROP of a not handled table, check if it has rows. If yes, copy the data or throw an error.
- deleteRankingSubquestions(): only delete when the ranking question still has rows in {{answers}}.

Related problems found in the same tests (I can file them separately if you want):
- After "kill -9" during "console.php updatedb", maintenancemode stays "hard", even after a successful second run.
- CLI updatedb does not clear the web schema cache (tmp/runtime/cache). console.php sets YII_DEBUG=true, so Yii::app()->cache->flush() only flushes CDummyCache. If a web page was opened during the update (for example the "update is already in progress" page), the web side caches the old (651) schema for up to 3600 s (schemaCachingDuration) and shows 500 errors after the update: Property "Survey.preselectnoanswer" is not defined / Unknown column 'survey.nokeyboard'.

20767: Stracktrace in new editor

Wed, 14 Oct 2026 16:47:41 +0200

There is a stacktrace when i click any survey based on the fruity theme with the new editor enabled:

REQUEST_URI=/rest/v1/survey-detail/674933
2026/10/13 15:16:52 [error] [php] simplexml_load_string(): Entity: line 1: parser error : Extra content at the end of the document (/var/www/limesurvey/application/models/TemplateManifest.php:1457)
Stack trace:
#0 /var/www/limesurvey/application/models/TemplateManifest.php(1457): simplexml_load_string()
#1 /var/www/limesurvey/application/models/services/SurveyThemeConfiguration.php(186): getOptionAttributes()
#2 /var/www/limesurvey/application/libraries/Api/Command/V1/Transformer/Output/TransformerOutputSurveyDetail.php(406): LimeSurvey\Models\Services\SurveyThemeConfiguration->updateCommon()
#3 /var/www/limesurvey/application/libraries/Api/Command/V1/Transformer/Output/TransformerOutputSurveyDetail.php(212): LimeSurvey\Api\Command\V1\Transformer\Output\TransformerOutputSurveyDetail->transformThemeSettings()
#4 /var/www/limesurvey/application/libraries/Api/Command/V1/SurveyDetail.php(117): LimeSurvey\Api\Command\V1\Transformer\Output\TransformerOutputSurveyDetail->transform()
#5 /var/www/limesurvey/application/libraries/Api/Rest/Endpoint.php(119): LimeSurvey\Api\Command\V1\SurveyDetail->run()
#6 /var/www/limesurvey/application/controllers/RestController.php(42): LimeSurvey\Api\Rest\Endpoint->run()
#7 /var/www/limesurvey/vendor/yiisoft/yii/framework/web/CWebApplication.php(282): RestController->run()
#8 /var/www/limesurvey/vendor/yiisoft/yii/framework/web/CWebApplication.php(141): LSYii_Application->runController()
#9 /var/www/limesurvey/vendor/yiisoft/yii/framework/base/CApplication.php(185): LSYii_Application->processRequest()
#10 /var/www/limesurvey/index.php(161): LSYii_Application->run()

20766: Error when running a different survey, upon closing the current one

Wed, 14 Oct 2026 14:25:58 +0200

The error described below blocks blocks the system for the user until session ends. It occurs both for admins and users working on subsequent surveys.
Re-opening the crashed survey or admin panel on a private window works.
Note: Looking at the cookies, the Session-ID changes every time a different survey is started. The error appears only after switching page from the welcome to another one.

20764: "All" string is untranslated in Survey Statistics Expert view

Tue, 13 Oct 2026 12:48:39 +0200

20763: "Search:" string is untranslated in Integration panel view

Tue, 13 Oct 2026 12:48:47 +0200

20761: MS-SQL Survey activation can remove unique index on response table

Mon, 12 Oct 2026 18:18:31 +0200

With MS-SQD : there are potential issue about the unique index in response table.
Sometimes receive an SQL error about a duplicate index after survey is activated: "duplicate index on INDEX_1234 ..."

20760: All-in-one survey: question stays visible after an answer change although the question group it depends on is hidden

Sat, 10 Oct 2026 08:42:20 +0200

In an all-in-one survey, a question whose condition uses a question from a later question group can stay visible after the participant changes an answer, even though that later group is hidden. The question only hides again after another answer change. If the participant fills it in, the answer is dropped on submit.

20751: Unclear error message when re-using existing survey alias

Tue, 06 Oct 2026 12:54:39 +0200

When you set a survey alias and then use that same alias for a different survey, there is an unclear error message

20747: missing file "_tutorial_menu.php"

Thu, 01 Oct 2026 16:23:46 +0200

After a manual upgrade to version 7.4.0, the following server error occurs:

500: Internal Server Error - DashboardController cannot find the requested view "/admin/super/_tutorial_menu".
An internal error occurred while the web server was processing the request.
Please contact the administrator to report this issue.

Cause:
Missing file "limesurvey/application/views/admin/super/_tutorial_menu.php"

Workaround:
Create a file named "_tutorial_menu.php" (even an empty one).

20737: Index with question by question mode visually roken + usage of nav

Tue, 29 Sep 2026 12:48:15 +0200

With vanilla: the index is visually broken, and don't use nav and navigation

20736: Better difference between No response and not activated

Sat, 10 Oct 2026 10:55:31 +0200

In survey listing : difference between "No response" and "No response tables" is unclear.

20734: When DB have an issue unable to fix it

Tue, 29 Sep 2026 12:13:15 +0200

If a survey is set as active== Y but the responses table are deleted or disappears (or any other error ) : no way to login and fix the issue.

20729: Calling export_responses over JSON-RPC with sDocumentType = "csv" always returns HTTP 500 with a TypeError.

Sun, 11 Oct 2026 06:00:05 +0200

Calling export_responses over JSON-RPC with sDocumentType = "csv" always returns HTTP 500 with a TypeError. The same call with "json" or "xls" succeeds on the same survey, same session and same user. CSV export from the admin web UI also works. The problem was already present on 6.x and persisted after upgrading to 7.3.0.

When EXPORT_FORMAT is "xls" or "json" works fine, when "csv" it errors. R code that produces error in step export_b64 <- ls_call:

ls_call <- function(method, params) {
body <- jsonlite::toJSON(list(method = method, id = 1, params = params),
auto_unbox = TRUE)
resp <- httr::POST(LS_API_URL, httr::content_type_json(), body = body)
if (httr::http_error(resp)) {
# Server-side failures put the actual reason in the body, usually as an
# HTML error page -- strip the markup and show just the readable text
txt <- httr::content(resp, as = "text", encoding = "UTF-8")
txt <- gsub("(?is)<(head|script|style)\\b.*?", " ", txt, perl = TRUE)
txt <- gsub("<[^>]+>", " ", txt)
txt <- trimws(gsub("\\s+", " ", txt))
stop(method, ": HTTP ", httr::status_code(resp), "\n", substr(txt, 1, 2000))
}
out <- jsonlite::fromJSON(httr::content(resp, as = "text", encoding = "UTF-8"))
if (!is.null(out$error)) stop(method, ": ", out$error)
if (is.list(out$result) && !is.null(out$result$status)) {
stop(method, ": ", out$result$status)
}
out$result
}

session_key <- ls_call("get_session_key", list(LS_USER, LS_PASSWORD))

export_b64 <- ls_call("export_responses", list(
session_key, survey$survey_id, EXPORT_FORMAT, survey$lang,
COMPLETION, HEADING_TYPE, RESPONSE_TYPE
))

So exporting in xls is the workaround, but given that csv is the standard for data exchange, it would be good to get the "csv" format working.

20726: Question attributes diverge between React editor and classic editor

Thu, 24 Sep 2026 21:36:11 +0200

This is a problem as fixes don't reach both editors. In some instances it is even worse as different question attributes are attributed to different question themes. For example this blocks a fix for 18721

20725: New Question-Editor - missing button/possibility to manual "Data Entry"

Thu, 24 Sep 2026 17:57:30 +0200

In the new (!) question editor i can't see a button or possibilty to enter the page "data entry" in a running survey in the category "results".
Even not in the "..."-menus.

20724: Page to define or import label sets is not reachable

Fri, 25 Sep 2026 08:30:13 +0200

Page to define or import label sets is not reachable.

20722: When check data integrity : if you have a old response table : it broke

Thu, 24 Sep 2026 17:59:53 +0200

When there are old response table data inetgrity result throiw a DB error

20719: Access mode button text is untranslated on state change

Fri, 16 Oct 2026 14:32:13 +0200

See screenshot below.

20718: error trying to update to 7.2

Wed, 23 Sep 2026 10:39:47 +0200

Call to undefined function getHtmlLangAttributeValue()

/var/www/limesurvey7/application/core/LSETwigViewRenderer.php(690)

678 // (in the future, should be template dependant done via XML file)
679 $aData["aSurveyInfo"] = array_merge($aData["aSurveyInfo"], $oTemplate->getClassAndAttributes());
680
681 $languagecode = App()->getLanguage();
682 if (!empty($aData['aSurveyInfo']['sid']) && Survey::model()->findByPk($aData['aSurveyInfo']['sid'])) {
683 if (!in_array($languagecode, Survey::model()->findByPk($aData['aSurveyInfo']['sid'])->getAllLanguages())) {
684 $languagecode = Survey::model()->findByPk($aData['aSurveyInfo']['sid'])->language;
685 }
686 }
687
688 $aData["aSurveyInfo"]['languagecode'] = $languagecode;
689 /* Separate from 'languagecode' since some codes (e.g. 'nl-informal') are not valid values for the HTML lang attribute */
690 $aData["aSurveyInfo"]['htmllanguagecode'] = getHtmlLangAttributeValue($languagecode);
691 $aData["aSurveyInfo"]['dir'] = (getLanguageRTL($languagecode)) ? "rtl" : "ltr";
692
693 if (!empty($aData['aSurveyInfo']['sid'])) {
694 $showxquestions = App()->getConfig('showxquestions');
695 $aData["aSurveyInfo"]['bShowxquestions'] = ($showxquestions == 'show' ||
696 ($showxquestions == 'choose' && !isset($aData['aSurveyInfo']['showxquestions'])) ||
697 ($showxquestions == 'choose' && $aData['aSurveyInfo']['showxquestions'] == 'Y'));
698
699
700 // NB: Session is flushed at submit, so sid is not defined here.
701 if (
702 isset($_SESSION['responses_' . $aData['aSurveyInfo']['sid']]) &&