Bug 121921 - UI: Error-Dialog appears, when Input is not set to required in a Field of a Form, is set in the Table
Summary: UI: Error-Dialog appears, when Input is not set to required in a Field of a F...
Status: RESOLVED DUPLICATE of bug 121188
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-05 13:37 UTC by Justin L
Modified: 2018-12-05 15:47 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
dataEntryErrorMessage.png: can't leave field blank error message (11.60 KB, image/png)
2018-12-05 13:37 UTC, Justin L
Details
tdf121921_emptyfielderror.odb: Donations form error preventing data entry (40.12 KB, application/vnd.oasis.opendocument.database)
2018-12-05 13:47 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2018-12-05 13:37:52 UTC
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
Comment 1 Justin L 2018-12-05 13:47:53 UTC
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.
Comment 2 Julien Nabet 2018-12-05 14:08:50 UTC
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.
Comment 3 Justin L 2018-12-05 14:23:16 UTC
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.
Comment 4 Drew Jensen 2018-12-05 15:00:13 UTC
(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.
Comment 5 Drew Jensen 2018-12-05 15:06:47 UTC
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.
Comment 6 Lionel Elie Mamane 2018-12-05 15:13:03 UTC
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.
Comment 7 Lionel Elie Mamane 2018-12-05 15:21:35 UTC
(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?
Comment 8 Drew Jensen 2018-12-05 15:26:30 UTC
(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 ***
Comment 9 Lionel Elie Mamane 2018-12-05 15:47:43 UTC
(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".