Description: I use debian packaged libreoffice with libreoffice-sdbc-postgresql driver. I do not know where the bug is. I have simple form based on postgresql table. In this table there is a column name type nullable default value utw timestamp without time zone not null now() This column does not have its field in form. With package: Package: libreoffice-base Version: 1:6.1.2-1 Package: libreoffice-sdbc-postgresql Version: 1:6.1.2-1 I cannot save filled form to database, because "required utw field has no value" When I drop "not null" from column, and restart libreoffice - form could be saved to database. When I tried with version: 1:6.1.1~rc1-2 of libreoffice packages its works as expected. PostgreSQL 10.5 (Debian 10.5-1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.2.0-3) 8.2.0, 64-bit Steps to Reproduce: 1. in postgres do "create table x (id serial primary key, x text, u timestamp with time zone not null default now());" 2. confgure connection to database with sdbc-postgresql driver 3. prepare form based on this table WITHOUT u field (example will be attached) 4. fill form 5. try to save record Actual Results: message: Input required in field 'u'. Please enter a value. Expected Results: insert a record Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 145303 [details] form for testing
I can reproduce this with : MacOS 10.13.6 postgres 9.5 LibreOffice 6.1.2.1 sdbc built-in postgres driver If I enter the data for a record in Table data edit mode, then the date is added automatically. However, like you, filling in a simple form including the timestamp field and leaving the timestamp field blank always throws an error when I try to move to either a new record, or back to a previous record. What should happen is that the timestamp value should be generated and the record validated (as in Table data edit mode).
If Postgres specifically, I never understood how Postgres worked. => Can't help here.
This most probably comes from the fix of bug 75341. First thought: What we should do is check whether the column has a default value set, and in this case accept that the form gives no value. But: 1) This will not work with PostgreSQL-sdbc because the driver doesn't quite implement reading/setting default values. 2) This is still not 100% correct; there may be a more subtle mechanism that makes not giving that column a value acceptable, although it is "NOT NULL" e.g. an INSERT trigger that will put a value, but no "default value" attached to the column. So LibreOffice shouldn't try to double-guess the database. Just throw the values entered by the user, and let the database return an error if needs be. The form designer can always require a value with a validator, with having the control's "value required" property set or with a beforeUpdate macro. Julien, please remove the "&& && rColInfo.nNullable != ColumnValue::NO_NULLS" from the commit that fixed bug 75341 completely. Thanks.
Julien, please see comment 4. Thanks.
(In reply to Lionel Elie Mamane from comment #5) > Julien, please see comment 4. Thanks. I take it.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8dbcd72f83e2317dd40c0fa605fd26b3f6a2616b&h=libreoffice-6-1 tdf#120245: Accept to insert empty field with 'not null' database constraint It will be available in 6.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=adb0030d99b90fc50e536c89fc8c7a80f057c6ac tdf#120245: Accept to insert empty field with 'not null' database constraint It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 120289 has been marked as a duplicate of this bug. ***
*** Bug 120337 has been marked as a duplicate of this bug. ***
*** Bug 120353 has been marked as a duplicate of this bug. ***
Unfortunately the fix has not got into the ubuntu pre-release: Version: 6.1.3.1 Build ID: 1:6.1.3~rc1-0ubuntu0.18.04.1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); Calc: threaded I had previously tested 6.1.3 from 5/10/18 and found it had fixed the issue. I have since run a slightly later version as below (downloaded for another issue) but the problem has returned: Version: 6.1.3.0.0+ Build ID: 7bafe2441480e2b88d999b30b7f117f05e72c3b3 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-6-1, Time: 2018-10-08_08:54:10 Locale: en-GB (en_GB.UTF-8); Calc: group threaded So forgive me if I'm breaking the rules, but I'be re-opened this issue.
(In reply to tim from comment #12) > ... > > I had previously tested 6.1.3 from 5/10/18 and found it had fixed the issue. >... You reproduced this exact bug with Postgresql or are you talking about tdf#120353?
Apologies. My mistake. I commented on the wrong issue. I've reset this status to Resolved Fixed.
I remarked on this one because my issue #120353 was called a duplicate of this one. I'll comment only on that one when I've retested with a later version of 6.1.3.
*** Bug 120704 has been marked as a duplicate of this bug. ***
*** Bug 120712 has been marked as a duplicate of this bug. ***
*** Bug 121188 has been marked as a duplicate of this bug. ***
@Julien : in duplicate bug 1211888, there is a report that the problem is still present. Did your commit fix not make into 6.1.3.1rc1 ?
(In reply to Alex Thurgood from comment #21) > @Julien : in duplicate bug 1211888, there is a report that the problem is > still present. > > Did your commit fix not make into 6.1.3.1rc1 ? Don't know but 6.1.3.2 has been released, see https://bugs.documentfoundation.org/show_bug.cgi?id=121188#c5