Bug 93724 - BASE: Insert Row in Filtered Form with Date/Time Fields results in Phantom zero date displayed instead of null, not saved
Summary: BASE: Insert Row in Filtered Form with Date/Time Fields results in Phantom ze...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:5.1.0 target:5.0.4
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2015-08-28 02:04 UTC by Doug
Modified: 2016-10-25 19:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
demonstration database: See Form1 and Macro (13.10 KB, application/vnd.oasis.opendocument.database)
2015-08-28 02:04 UTC, Doug
Details
Correct display of values in LO330 (33.36 KB, image/png)
2015-08-28 09:15 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Doug 2015-08-28 02:04:31 UTC
Created attachment 118240 [details]
demonstration database:  See Form1 and Macro

1  .In Base, you have a form, we'll call Form1.  See demo attachment for reproducing.
2.  There are two defining characteristics of Form1:  a.)  it has an entry in the Filter property for MainForm and b.) it has a date/time field.
3.  Open Form1
4.  Navigate beyond the last row of data in Form1 to the Insert Row.
5.  Type Something in the bottom-most field (a text field)
6.  Press the save record button or navigate back to the first row

UNEXPECTED RESULT:  the date field at the top has gone from the desired NULL/EMPTY input to a zero date which in this case is 1/1/1800.

Alternately, you can reproduce using the macro saved in the database which does the same thing, basically.  The 0-date 1/1/1800 is persistent in the Form1 recordset until it is closed (no matter if you navigate to other records) but it is not saved to the table.

The workaround is to delete the filter on the form.  However, that is a non-obvious workaround because why would there be a connection between the way the date is displayed and the existence of a filter on another field....
Comment 1 Doug 2015-08-28 02:06:39 UTC
Using LO 5.0.1.1 on Linux OpenSuse 13.2 KDE.  Also reproduced on Windows 7 64-bit LO 5.0.0.5 and LO 4.5.  I think this has been a problem going back through many versions.
Comment 2 Alex Thurgood 2015-08-28 09:07:04 UTC
Confirming on OSX 10.10.5 with

Version: 4.1.4.2
Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

I also see that default date entry flash briefly on screen when switching from one record set containing a still empty date field to the next record containing the automatically displayed default date.
Comment 3 Alex Thurgood 2015-08-28 09:14:36 UTC
The form appears to behave correctly in 

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

see attached screenshot

==>> regression
Comment 4 Alex Thurgood 2015-08-28 09:15:14 UTC
Created attachment 118241 [details]
Correct display of values in LO330
Comment 5 Alex Thurgood 2015-08-28 09:23:12 UTC
To re-situate the context, that default 00/00/0000 displayed value was always the way that OpenOffice.org displayed null date values in forms, in which case, if I am to understsand Doug's comments correctly, even this would be incorrect for him, as he wants a completely blank control.

As I recall, the zero date display was a much griped about "feature" of previous versions of OpenOffice.org, the only difference between then and now being that the controm field displays the default date of LibreOffice as the null date, i.e. 1/1/1800 as defined in Calc (go figure).

So, the regression I refer to is not in the problem of the actually displaying a null value per se, but the fact that the previous zeroed out "00/00/0000" display now shows Calc's default date setting instead.
Comment 6 Doug 2015-08-28 11:09:34 UTC
Yes, I would like the blank date control before the InsertRow method to stay blank after the InsertRow method is executed.  No reason why the InsertRow method should change the appearance or value of the date control in this situation.

This is a bug for me because the zero date behavior is inconsistent, both with the way the form works when there is no filter, and inconsistent with the value actually reported back to the table.  If you close and open the form again and browse back to the same record the date will be reported correctly as null, even though when it was recorded LO said it was a zero date.  So if this was a limitation of how LO or OO works, that would be one thing, but instead it just seems like an anomaly.
Comment 7 Doug 2015-08-28 11:13:11 UTC
The functionality also was impervious to changing ODBC settings on a MySQL back-end to report zero-dates as null.  Proper functionality would have been responsive to that option.
Comment 8 Robert Großkopf 2015-08-28 14:13:58 UTC
Have tested it with LO 3.5.7.2 - the same bug: the field should be empty, but shows a date 1/1/1800.
Same behavior in date/time and date-fields.
So I set this version to 3.5.7.2 - the oldest version I have tested.

My system: OpenSUSE 13.2 64bit rpm Linux.
Comment 9 Terrence Enger 2015-08-29 01:14:14 UTC
The bug, meaning that the added record shows date 1800-01-01 upon
redisplay, is already present in the earliest bibisect version that I
can find for Linux, bibisect_linux_x86_64_lo35_and_later version
oldest, which identifies itself as

    LibreOffice 3.5.0 
    Build ID: d6cde02

I am setting version in this report to 3.5.0 release.

So far as I know, this leaves OS/X as the only plausible way go
further with bibisect.


I once thought I could fix the form definition to give much better
results using daily dbgutil bibisect version 2015-08-28, but now I
cannot do it again.  I think I have to give up for now.
Comment 10 Lionel Elie Mamane 2015-10-20 16:30:30 UTC
This happens only if the current filter does not match the newly inserted record. In the attachment 118240 [details], since the filter is "text 1 = 't'", this bug does not appear if the new record has value 't' in text1.
Comment 11 Commit Notification 2015-10-30 11:24:32 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=11ce80e1e7085e2073850056e47e4e997905d286&h=libreoffice-5-0

tdf#93724 KeySet insert: properly set default values: NULL & right type

It will be available in 5.0.4.

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 12 Robinson Tryon (qubit) 2015-12-17 10:32:13 UTC Comment hidden (obsolete)