Bug 75341 - UI: No Error-Dialog appears, when Input is set to required in a Field of a Form, but not set in the Table
Summary: UI: No Error-Dialog appears, when Input is set to required in a Field of a Fo...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Julien Nabet
URL:
Whiteboard: target:6.2.0 target:6.1.2
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-21 20:56 UTC by Robert Großkopf
Modified: 2023-03-14 02:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2014-02-21 20:56:28 UTC
In a form you could chose for every field the property "Input required". This property doesn't do anything if there isn't set "Input required" also in the table, which should be filled by the form.

Expected behavior: You could chose "Input required" in a field of a form and the dialog of an error occurs, if there is missing input. This error should appear, if there is "Input required" set in the form or set in the table (through SQL) or in both ways - but it isn't shown only, when it is set in both ways.

See https://bugs.freedesktop.org/attachment.cgi?id=94532 for an example. Open the form "Table_Input_requred_GUI". You could save data without any content except the primarykey "ID". But all fields were set to "Input required" in the GUI of the form.
Comment 1 Buovjaga 2014-11-08 14:32:23 UTC
Reproduced. All the columns have Input required: Yes, but it still allows to save without content.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: c989f5e0e11e295b11ffc921b0d105869e037e47
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-07_22:50:48
Comment 2 Alex Thurgood 2015-01-03 17:39:34 UTC Comment hidden (no-value)
Comment 3 QA Administrators 2017-05-22 13:20:08 UTC Comment hidden (obsolete)
Comment 4 Robert Großkopf 2017-05-28 17:30:50 UTC
Bug still exists with LO 5.4.0.0.beta1, OpenSUSE 42.1 Leap, 64bit rpm Linux.
Comment 5 QA Administrators 2018-05-29 02:36:57 UTC Comment hidden (obsolete)
Comment 6 Robert Großkopf 2018-05-29 05:42:02 UTC
Bug still exists with LO 6.0.4.2, OpenSUSE 42.3 Leap, 64bit rpm Linux.
Comment 7 Julien Nabet 2018-09-06 07:36:40 UTC
I think it could be interesting to test this again following tdf#91837 fix.
I'll give it a try.
Comment 8 Julien Nabet 2018-09-06 17:51:51 UTC
(In reply to Julien Nabet from comment #7)
> I think it could be interesting to test this again following tdf#91837 fix.
> I'll give it a try.

I could still reproduce this
Comment 9 Julien Nabet 2018-09-06 19:01:49 UTC
I gave a try with https://gerrit.libreoffice.org/#/c/60109/
Comment 10 Commit Notification 2018-09-07 05:02:17 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dbb444e4ed7c19a11733ce8438bbb6546d42f852

tdf#75341: fix condition to approve row (form)

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.
Comment 11 Julien Nabet 2018-09-07 06:48:46 UTC
Backports in gerrit waiting for review
6.1: https://gerrit.libreoffice.org/#/c/60125/
6.0: https://gerrit.libreoffice.org/#/c/60126/
Comment 12 Julien Nabet 2018-09-07 08:38:45 UTC
Just for information, since analyzing consequences of the patch on 6.0 may take some time and 6.0 branch will be soon EOL , the fix won't be backport on it.
Comment 13 Commit Notification 2018-09-07 10:01:14 UTC
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=3448ca93eb46365d05387f7f3512c706bdb987c4&h=libreoffice-6-1

tdf#75341: fix condition to approve row (form)

It will be available in 6.1.2.

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.
Comment 14 Peter Toye 2018-12-15 09:47:40 UTC
This is all very well, but you don't seem to have thought of the number of people who have forms with the default setting of "Input required" - which appears to be "Yes". Now we have to go through all of our databases, through all of the forms, and for all of the fields set it to "no" where appropriate. A mega-PITA IMHO.
Comment 15 Robert Großkopf 2018-12-15 10:22:41 UTC
(In reply to Peter Toye from comment #14)
> This is all very well, but you don't seem to have thought of the number of
> people who have forms with the default setting of "Input required" - which
> appears to be "Yes". Now we have to go through all of our databases, through
> all of the forms, and for all of the fields set it to "no" where
> appropriate. A mega-PITA IMHO.

Have a look here: https://bugs.documentfoundation.org/show_bug.cgi?id=120353#c27

As I understand: Input Required will be set to "No" automatically when opening an older form by LO 6.1.4

Dosen't this work for you?
Comment 16 Peter Toye 2018-12-20 11:47:06 UTC
Doesn't seem to have worked. Just opened a base document dated March 2018. It's insisting on my putting data in a field that I don't want filled. I'm trying to write a macro to go through all forms in a document and convert all the fields to "not required". It'll take some time, given the arcane API.
Comment 17 Lionel Elie Mamane 2018-12-20 11:50:23 UTC
(In reply to Peter Toye from comment #16)
> Doesn't seem to have worked. Just opened a base document dated March 2018.

With what version of LibreOffice?
Comment 18 Peter Toye 2018-12-20 17:55:27 UTC
6.1.3.2 64-bit running on Windows 7.
Comment 19 Julien Nabet 2018-12-20 17:57:07 UTC
(In reply to Peter Toye from comment #18)
> 6.1.3.2 64-bit running on Windows 7.

Please give a try to brand new 6.1.4 version. Indeed, it should be fixed.
Comment 20 Peter Toye 2018-12-20 18:22:57 UTC
"Check for updates" says my LO is up to date. I'm downloading 6.1.4 manually. I just spent a frustrating hour changing all the "input required" controls to "no" :(
Comment 21 Peter Toye 2018-12-20 18:32:30 UTC
All fields (including those I'd originally marked as "Yes" are now "No". At least there are fewer of them!
Comment 22 Robert Großkopf 2022-08-23 16:59:57 UTC
Have tested this again and again. Bug isn't fixed.

If I set a field in LO 7.4.0.3 as "Input Required" in a form, not in the table, nothing will happen in the form.

I will reopen the bug. The patch only sets fields in older forms to "Input Required" → 'No'. But it doesn't change the behavior to give a warning, if no content is in a field I have set "Input Required" → 'Yes' and I save the row.
Comment 23 Julien Nabet 2022-08-23 18:44:54 UTC
Let's put this one to NEW and since I can't help here, unassign and uncc myself.
Comment 24 Mike Kaganski 2022-08-24 06:25:18 UTC
Undoing all the damage done here by reopening, that led to clearing all *important* metadata like assignee, target, etc.

Please do not reopen bugs that had "fixed" status for more than a year (this had it for almost four years). Comment 14 (and later discussion with Peter, and bug 120353) clearly indicate that the fix was effective. So anything that happened later, including something having exactly the same symptoms, must be filed separately, with this bug put in See Also.

Thanks for understanding.
Comment 25 ayudame911 2023-03-14 02:51:09 UTC Comment hidden (spam)