Can't create form : Unknown column 'allow_edit_submissions' in 'field list'
Please use the 👍 reaction to show that you are affected by the same issue. Please don't comment if you have no relevant information to add!
Describe the bug Impossible to create a new form after upgrade to NC 31
To Reproduce Not sure
Expected behavior No error when creating form
Screenshots If applicable, add screenshots to help explain your problem.
Nextcloud (please complete the following information):
- Nextcloud-Version: 31.0.8 / 31.0.9
- Forms-Version: 5.2.1
Desktop (please complete the following information):
- OS: Debian SID
- Browser: firefox
- Version: 143.0.3 (64 bits)
Browser log
POST https://cloud.*****.**/ocs/v2.php/apps/forms/api/v3/forms 500
<?xml version="1.0"?>
<ocs>
<meta>
<status>failure</status>
<statuscode>996</statuscode>
<message>Internal Server Error
</message>
</meta>
<data/>
</ocs>
** Nextcloud log**
[no app in context] Erreur: An exception occurred while executing a query: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'allow_edit_submissions' in 'field list'
POST /ocs/v2.php/apps/forms/api/v3/forms
"message": "An exception occurred while executing a query: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'allow_edit_submissions' in 'field list'",
"exception": {
"query": "INSERT INTO `*PREFIX*forms_v2_forms` (`owner_id`, `hash`, `title`, `description`, `access_enum`, `submit_multiple`, `allow_edit_submissions`, `show_expiration`, `expires`, `is_anonymous`, `created`, `last_updated`) VALUES(:dcValue1, :dcValue2, :dcValue3, :dcValue4, :dcValue5, :dcValue6, :dcValue7, :dcValue8, :dcValue9, :dcValue10, :dcValue11, :dcValue12)"
},
Additional context Add any other context about the problem here.
@wargreen it looks like some DB migration to the latest scheme didn't run during your latest Forms updates... Did you see any error messages while updating Forms/Nextcloud?
No issue at all nor errors when upgrading...
@wargreen could you please run occ upgrade and see if this runs the migration steps?
https://docs.nextcloud.com/server/stable/admin_manual/occ_command.html#command-line-upgrade
sudo -u www-data php occ upgrade
No upgrade required.
Yesterday, after seen this issue, i've upgraded from 31.0.8 to 31.0.9 for see if the upgrade fix that. And no luck !
could you please use this command and look at the output?
NC_debug=true sudo -u www-data php occ migrations:status forms
If there are 'pending' migrations or 'Next version' doesn't state that your at the latest migration step, please run this afterwards:
NC_debug=true sudo -u www-data php occ migrations:migrate forms
I got :
Command "migrations:status" is not defined.
Did you mean one of these?
encryption:status
migrations:preview
twofactorauth:state
NC_debug=true sudo -E -u www-data php occ migrations:migrate forms
Sorry I forgot the -E flag...
The output is empty
Did you only run the command in my last post or did you add the -E parameter to the first command as well? The second one normally doesn't show no output if there's no error. Could you try to create a new form again?
Old form data does not have this attribute, therefore the code fails trying to access this attribute. The attached patch sets default (false) if this attribute does not exist. Use at your own risk...
@sbaecker this wouldn't help in this case here. We're talking about creating a new form in the latest Forms app version. FormsMigrator.php only comes into action when a user exports/imports his/her user data.
Forms app didn't want to start on our site (NC 31.0.5), neither with old forms nor for creation of new ones. No explicit import or exports involved. Logfile showed problems with that same attribute, but not within the database - correct.
I checked migrations according to your suggestions - all were up to date.
Maybe topic starter will head into same trouble as we did, once his migrations are fixed.
We are running Nextcloud version 31.0.9 Enterprise and Forms 5.2.1, same issue.
# NC_debug=true /usr/bin/sudo -E -u www-data /usr/bin/php --define apc.enable_cli=1 /var/www/nextcloud/occ migrations:migrate forms ; echo $?
0
# /usr/bin/sudo -E -u www-data /usr/bin/php --define apc.enable_cli=1 /var/www/nextcloud/occ migrations:migrate forms ; echo $?
Command "migrations:migrate" is not defined.
Did you mean one of these?
circles:migrate:customgroups
encryption:migrate-key-storage-format
migrations:preview
1
Ah, I get it, the command only appears when the variable is set. Some more information:
# NC_debug=true /usr/bin/sudo -E -u www-data /usr/bin/php --define apc.enable_cli=1 /var/www/nextcloud/occ migrations:status forms
>> App: forms
>> Version Table Name: oc_migrations
>> Migrations Namespace: OCA\Forms\Migration
>> Migrations Directory: /var/www/nextcloud/apps/forms/lib/Migration
>> Previous Version: 050200Date20250109201500
>> Current Version: 050200Date20250512004000
>> Next Version: Already at latest migration step
>> Latest Version: 050200Date20250512004000
>> Executed Migrations: 34
>> Executed Unavailable Migrations: 34
>> Available Migrations: 34
>> New Migrations: 34
>> Pending Migrations: None
@abruening-iwt ok, thanks. this shows that your database schema should be up-to-date and that the needed columns should be available. Could you please verify in the database that the column really exists in the table?
@wargreen @sbaecker @abruening-iwt could you please tell us which database you're using?
We us MySQL, the column is not there, assuming I'm looking at the right table:
MariaDB [nextcloud]> describe oc_forms_v2_forms;
+--------------------+----------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------------+----------------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| hash | varchar(64) | NO | UNI | NULL | |
| title | varchar(256) | YES | | NULL | |
| description | text | YES | | NULL | |
| owner_id | varchar(64) | NO | MUL | NULL | |
| created | int(11) | YES | MUL | NULL | |
| expires | int(11) | YES | | 0 | |
| is_anonymous | tinyint(1) | YES | | 0 | |
| submit_multiple | tinyint(1) | YES | | 0 | |
| show_expiration | tinyint(1) | YES | | 0 | |
| last_updated | int(11) | YES | | 0 | |
| submission_message | varchar(2048) | YES | | NULL | |
| file_id | bigint(20) unsigned | YES | | NULL | |
| file_format | varchar(5) | YES | | NULL | |
| state | smallint(5) unsigned | NO | | 0 | |
| access_enum | smallint(5) unsigned | YES | | NULL | |
| locked_by | varchar(255) | YES | | NULL | |
| locked_until | int(11) | YES | | NULL | |
+--------------------+----------------------+------+-----+---------+----------------+
18 rows in set (0.001 sec)
MariaDB 10.11 We have that column.
@abruening-iwt sounds like the update was not really successful.
Try running occ migrations:migrate forms Version050200Date20250109201500
@abruening-iwt sounds like the update was not really successful. Try running
occ migrations:migrate forms Version050200Date20250109201500
The command completes successfully without output (even with -vvv), the column remains absent.
No output is normal in this case. That the column still doesn't exist, however, isn't...
Should I create it manually?
This would at least fix the issue for you, yes.
$table->addColumn('allow_edit_submissions', Types::BOOLEAN, [
'notnull' => false,
'default' => 0,
That's how it should look like :)
Adding the column manually did solve the issue for me.
Still unclear why it did not create the column for you, but it works everywhere else (we use this kind of migrations everywhere).
The only difference I could spot is this line:
https://github.com/nextcloud/forms/blob/b0f26c5f28ed306eda6c45a7f4e606f5b0c252b6/lib/Migration/Version050200Date20250109201500.php#L34
It should be 'default' => false, instead - but should normally still work.
We have lots of migrations containing the 'default' => 0 for boolean fields. So there might be some other circumstances that cause the migration not to run successfully.
We're having the same issue, none of the upper commands helped. We were running Nextcloud version 31.0.8 and Forms 5.2.0 when the problem appeared the first time. I tried it on 31.0.9 and now 32.0.0.13 as well Forms 5.2.1 but same issue. Console is giving me:
forms: Unable to create new form {app: 'forms', uid: 'mf_cloud_admin', level: 2, error: R} Failed to load resource: the server responded with a status of 500 () -> /ocs/v2.php/apps/forms/api/v3/forms:1 {"message":"A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received"}
Our database: innodb_version | 10.6.22 version | 10.6.22-MariaDB-0ubuntu0.22.04.1
Thanks a lot!
@tim-tation what is the error message? Meaning from the nextcloud.log file?
Because {"message":"A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received"} seems like a CORS error message by your browser.
That was just additional information, same as thread: Error | no app in context | DbalExceptionAn exception occurred while executing a query: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'allow_edit_submissions' in 'INSERT INTO'
@wargreen @sbaecker @abruening-iwt could you please tell us which database you're using?
Sorry for the delay. We use MySQL / mariaDB
Did you only run the command in my last post or did you add the -E parameter to the first command as well?
Yes i do. I've retry now and same : no output.
Try running occ migrations:migrate forms Version050200Date20250109201500
Same issue after this command
If it can help :
root@tnd-cloud:/srv/nextcloud# NC_debug=true sudo -E -u www-data php occ migrations:status forms
>> App: forms
>> Version Table Name: oc_migrations
>> Migrations Namespace: OCA\Forms\Migration
>> Migrations Directory: /srv/nextcloud/apps/forms/lib/Migration
>> Previous Version: 050200Date20250109201500
>> Current Version: 050200Date20250512004000
>> Next Version: Already at latest migration step
>> Latest Version: 050200Date20250512004000
>> Executed Migrations: 34
>> Executed Unavailable Migrations: 34
>> Available Migrations: 34
>> New Migrations: 34
>> Pending Migrations: None
@wargreen @tim-tation do you maybe have two forms folders in different app directories?
Or maybe someone of you still got the update logs?
Because I am not able to reproduce this.