Created attachment 147301 [details] dataEntryErrorMessage.png: can't leave field blank error message In the table, the second and third columns are required to be non-null, but the last 3 columns are allowed to be empty. But even though the form has filled in the first three columns, an error message prevents moving to the next record until every column has a value. This has been working for years, but broke in 6.1. I bibisected to 6.1.2 backport author Julien Nabet 2018-09-07 12:00:24 +0200 commit 3448ca93eb46365d05387f7f3512c706bdb987c4 tdf#75341: fix condition to approve row (form) However, testing in master is fine. I bibisected that to the seemingly unlikely author Julien Nabet 2018-09-15 04:01:06 +0200 commit e005ab5d40d358adb75a64e140d46f4bf605647d Micro-optim in FormController::approveRowChange
Created attachment 147302 [details] tdf121921_emptyfielderror.odb: Donations form error preventing data entry Steps to reproduce: 1.) open the donations form and create a new entry. 2.) fill in the first three items (name, amount, date) but leave the last three items empty (thank-you, thank-date, note). 3.) move to the next new record. 6.1.3 errors that the fields thank-you date and note may not be null. None of the columns are required actually.
Justin: Just to be sure, do you have problem using second attachment with master sources or, like first attachment, you've got the problem only with 6.1.3? I agree with you, I don't know how the "micro-optim" commit may have fixed anything here. I'll try to reproduce this when get back to home. Lionel: put you in cc since you may be interested in this one.
I have the problem in bibisect-linux-64-6.2 only from Sept 7 till Sept 15. My master compile from Nov 8 is fine. P.S. Obviously I have not migrated the database to firebird, and that shouldn't be done in the testing either... (In reply to Justin L from comment #0) > In the table, the second and third columns are required to be non-null Sorry - that was just an assumption that I hadn't confirmed, and which isn't true. None of the fields are actually required. Those are the fields I always fill in when I do data-entry.
(In reply to Justin L from comment #3) > I have the problem in bibisect-linux-64-6.2 only from Sept 7 till Sept 15. > My master compile from Nov 8 is fine. > > P.S. Obviously I have not migrated the database to firebird, and that > shouldn't be done in the testing either... > > (In reply to Justin L from comment #0) > > In the table, the second and third columns are required to be non-null > Sorry - that was just an assumption that I hadn't confirmed, and which isn't > true. None of the fields are actually required. Those are the fields I > always fill in when I do data-entry. Ok, so I have the example database and in 6.1 I do get the error message if I fail to enter data in any of the fields - all of the UI controls on the form as marked as 'required input' while none of the columns in the table (save the key) are. This is what I would expect from the form. If I open this file with LO 5.4, 6.2Beta1 or the latest master build (6.3Alpha0) the form does not honor the required setting on the UI controls. This is all using the hsql sdbc (no migration used), btw. So there is already issues on this IIRC - off to look.
So there is this issue https://bugs.documentfoundation.org/show_bug.cgi?id=120245 " LibreOffice forms refuses to insert empty field with 'not null' database constraint (but filled by trigger or default value)" which is reported against postgres database, and is a bit different than what is happening here IMO There is also this one https://bugs.documentfoundation.org/show_bug.cgi?id=121188 "forms controls are created with "input required" set to yes by default " certainly related but not really the same issue either.
https://wiki.documentfoundation.org/ReleaseNotes/6.1#Base In the form, the Date field "datthankyou_date" bound to the table column thankyou_date has the property "Input required" set to "yes". So the form is configured to require a value there, independently of whether the database table requires it. In prior versions, this was not enforced. This was a bug which got corrected.
(In reply to Justin L from comment #0) > However, testing in master is fine. If master doesn't enforce the form's "input required", that is a bug in master. Can anybody confirm this?
(In reply to Lionel Elie Mamane from comment #7) > (In reply to Justin L from comment #0) > > However, testing in master is fine. > > If master doesn't enforce the form's "input required", that is a bug in > master. Can anybody confirm this? NO and I didn't fully understand the other issue, I thought it was only a problem if the form was created using 6.1.x but it was different than that. So using 6.1.2 I open the example file's form in edit mode and check each of the UI controls is marked required. Open the file using 6.2.1 and that form (unchanged) in edit mode and the UI controls show they are not required, and to finish that I tried 6.1.3 and it still shows required, then tried 6.1.4 and it is back to not required for those controls. Setting as dupe or 121188 *** This bug has been marked as a duplicate of bug 121188 ***
(In reply to Drew Jensen from comment #8) > (In reply to Lionel Elie Mamane from comment #7) >> If master doesn't enforce the form's "input required", that is a bug in >> master. Can anybody confirm this? > So using 6.1.2 I open the example file's form in edit mode and check each of > the UI controls is marked required. > Open the file using 6.2.1 and that form (unchanged) in edit mode and the UI > controls show they are not required, and to finish that I tried 6.1.3 and it > still shows required, then tried 6.1.4 and it is back to not required for > those controls. Yes, I did that as part of the fix to bug 121188, but forgot. In LibreOffice 6.1.4 and later, form controls in odb files last saved in earlier versions that have "input required: yes" will switch to "input required: no".