View Issue Details

This issue affects 1 person(s).
 10
IDProjectCategoryView StatusLast Update
20412Bug reportsDatabase designpublic2026-11-01 14:56
Reporterzufolo441 Assigned Toc_schmitz  
PrioritynoneSeverityminor 
Status resolvedResolutionfixed 
Summary20412: Subquestion field names in LS 7.0 Beta 1
Description

Hi, maybe there is some problem in field naming. I read in https://www.limesurvey.org/manual/LimeSurvey_7_Fieldname_Refactor that subquestion
are renamed Q<questionId>_S<subquestionId> , but in my test DB names are: Q<questionId>_S<questionId+subquestionId> .
Please see screenshot.
Question 2453 has answers with code 1~13.
Question 2435 is even more curious. has answers with code 1~9

Steps To Reproduce

Steps to reproduce

(Replace this text with detailed step-by-step instructions on how to reproduce the issue)

Expected result

(Write here what you expected to happen)

Actual result

(Write here what happened instead)

TagsNo tags attached.
Attached Files
ls7.png (385,334 bytes)
ls7_Q2435.png (68,988 bytes)   
ls7_Q2435.png (68,988 bytes)   
ls7_Q2453.png (103,859 bytes)
Bug heat10
Complete LimeSurvey version number (& build)7.0 beta 1
I will donate to the project if issue is resolvedNo
BrowserFirefox 147
Database type & versionPostgreSQL 17.7
Server OS (if known)RHEL 9
Webserver software & version (if known)
PHP Version8.2
Git branch / Pull Request URL

Users monitoring this issue

DenisChenu

Activities

zufolo441

zufolo441

2026-01-30 15:12

reporter   ~84151

Stop. I just understand the logic. it is not the "title" field but "qid" of subquestion.
So, in v7, how does the answers restore works?

zufolo441

zufolo441

2026-01-30 15:26

reporter   ~84152

I've just done a test. if I delete a subquestion ad I recreate with same code (title), it doesn't restore data from oldresponses$sid_$timestamp. In my opinion it's a bit problematic.

DenisChenu

DenisChenu

2026-01-30 16:11

developer   ~84153

I've just done a test. if I delete a subquestion ad I recreate with same code (title), it doesn't restore data from oldresponses$sid_$timestamp. In my opinion it's a bit problematic.

If you do same in 6.X and it work: yes, it's problematic. Must be reported separately.

(I think we try to use Expression Code for column names in 7.X or 8.X, I don't really understand the interest here.)

zufolo441

zufolo441

2026-01-30 16:20

reporter   ~84154

in v6 it works, because code is part of the field name....
in screenshot you can see fields for subquestion of question 2453. If I delete and recreate a subquestion with code "13" I obtain the same field name and I can restore field values.

ls6_fields.png (181,985 bytes)
DenisChenu

DenisChenu

2026-01-30 16:22

developer   ~84155

in v6 it works, because code is part of the field name....

Then it's clearly an issue : no question here !

tibor.pacalat

tibor.pacalat

2026-02-02 12:36

administrator   ~84159

The premise is correct, the new fieldname looks like Q<qid>_S<sqid>, where qid is the id of the main question and sqid is the id of the subquestion. There are many other forms, depending on the type, however, there is a misunderstanding that we need to clarify first.

Whilst the title of the subquestion or the code of the answer was an identifier in LS6, this is no longer the case. So the 2454 in your Q2453_S2454 is no 2453 + 1, but a qid of 2454, which happened to be created as the next question after the one with the qid of 2453 was created and since qid is incremental, its value happened to be 2454, but there is no causal relation between it being the code of 1 and the main question being 2453 and the result of 2454. If you remove a subquestion and recreate a new one with the same code, it will have a different qid. Your 2436 in Q2435_S2436 happened to be the next question to be created after 2435, however, your 2443 in Q2435_S2443 was created later, there were a few questions created in-between.

Since the title/code is no longer identifying a fieldname and since we use the actual identifier to identify it, if you had, say Q2435_S2436 and it had a code of 1, you deactivated the survey, removed this subquestion and created a new one with a code of 1, then that new subquestion will have a different qid from 2436 and hence upon reactivation its values will not hydrate your newly created field.

Indeed, that worked in LS6, but it's no longer the case in LS7 because the fieldnames are no longer reliant on code/title and therefore this is why your values were not brought back. We could enhance the reactivation screen with a mapping between what seem to be valid connections between old and new fields which have the same code and main question id so they could be brought back, but we'll need to discuss this idea with decision-makers before we can promise anything.

DenisChenu

DenisChenu

2026-02-02 12:39

developer   ~84160

that worked in LS6, but it's no longer the case in LS7

Then it's not an improvement! It's a new issue.

I always use VV export/import because it's better. But clearly, it's a new issue here.

zufolo441

zufolo441

2026-02-02 15:07

reporter   ~84161

Thank you all for the answers.
In this situation, for being sure data are recovered, I need to export/import in VV, which caption in row 2 is qcode_scode.
I agree the new field names schema, that wipes away useless group id and finally starts with char instead of digit, but it creates this problem in rehydrating table.

c_schmitz

c_schmitz

2026-11-01 14:56

administrator   ~87071

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=41219

Related Changesets

LimeSurvey: master 7ed971d1

2026-11-01 14:51

c_schmitz


Details Diff
Fixed issue 20412: Answers to a subquestion that was deleted and re-created with the same code while the survey was inactive were not restored on reactivation
Dev Deactivation now also archives the subquestion code and scale; restoring on activation and importing from a deactivated survey table map the archived columns of such subquestions to the re-created subquestion
Dev getDeactivatedArchives() found archive tables with LIKE '%<sid>%', so reactivating could restore the archive of another survey whose ID or archive timestamp contains the survey ID; it now matches the exact table name
Dev Restoring responses on activation failed with a database error on MSSQL, as its case-insensitive collation made getUnchangedColumns() treat the quota_exit column as a question column; question columns now need a digit after the Q
Dev The import from a deactivated survey table checked the encryption of the target column using the archived column name
Dev testResponseImport now quotes its column names, as it failed on PostgreSQL
Affected Issues
20412
mod - application/controllers/admin/DataEntry.php Diff File
mod - application/helpers/admin/import_helper.php Diff File
mod - application/models/services/SurveyDeactivate.php Diff File
mod - tests/functional/backend/ImportResponsesTest.php Diff File
add - tests/unit/helpers/GetDeactivatedArchivesTest.php Diff File

Issue History

Date Modified Username Field Change
2026-01-30 13:16 zufolo441 New Issue
2026-01-30 13:16 zufolo441 File Added: ls7.png
2026-01-30 13:16 zufolo441 File Added: ls7_Q2435.png
2026-01-30 13:16 zufolo441 File Added: ls7_Q2453.png
2026-01-30 15:12 zufolo441 Note Added: 84151
2026-01-30 15:12 zufolo441 Bug heat 0 => 2
2026-01-30 15:26 zufolo441 Note Added: 84152
2026-01-30 16:09 DenisChenu Issue Monitored: DenisChenu
2026-01-30 16:09 DenisChenu Bug heat 2 => 4
2026-01-30 16:11 DenisChenu Note Added: 84153
2026-01-30 16:11 DenisChenu Bug heat 4 => 6
2026-01-30 16:20 zufolo441 Note Added: 84154
2026-01-30 16:20 zufolo441 File Added: ls6_fields.png
2026-01-30 16:22 DenisChenu Note Added: 84155
2026-02-02 12:36 tibor.pacalat Note Added: 84159
2026-02-02 12:36 tibor.pacalat Bug heat 6 => 8
2026-02-02 12:39 DenisChenu Note Added: 84160
2026-02-02 15:07 zufolo441 Note Added: 84161
2026-02-02 17:05 tibor.pacalat Status new => confirmed
2026-11-01 14:56 c_schmitz Changeset attached => LimeSurvey master 7ed971d1
2026-11-01 14:56 c_schmitz Note Added: 87071
2026-11-01 14:56 c_schmitz Assigned To => c_schmitz
2026-11-01 14:56 c_schmitz Status confirmed => resolved
2026-11-01 14:56 c_schmitz Resolution open => fixed
2026-11-01 14:56 c_schmitz Bug heat 8 => 10