Created attachment 112427 [details]
Open "Form_Date_Datefield", input a wrong date-value like 31.6.14. Do the same in the table.
Open the attached database.
The following steps were made with German GUI and Schema:
You will see two fields, no entry is made.
Set ID '1' and Date '31.6.14', which is a wrong date-value.
Go to next row.
You will see the date from today instead.
Close the form, open the table directly for inpu data. Type ID '2' and Date '31.6.14'. Date will show '30.12.99', which means '1899-12-30'. Change this value to a normal existing value, for example '16.01.15'.
Reopen the form.
Put in a new date-value:
Set ID '3' and Date '31.6.14', which is a wrong date-value.
Go to next row.
You will see the date from row 2 instead of the wrong input.
Wrong date-value in a date-field in a form give the date of now, if there isn't a value in last row. If it finds a value in last row it will use this value.
Now try the other "Form_Date_formatted_Field". This does work exactly as the table itself would work: wrong entry gives '1899-12-30' - which istn't correct, but better than using a value, which seems to be correct. The behavior of the datefield could led to dataloss. So I set the Severity to major.
Confirming also on
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
on OSX 10.10.1
This rings a bell with regard to the use of today's date as default when in a form control, but can't remember whether it is a deliberate change or not. Unofrtunately, this new behaviour is inconsistent with the behaviour of the grid in Table view data entry mode.
Bug appears also in the first available LO-version (LO 220.127.116.11, OpenSUSE 42.1 64bit rpm Linux). So I set this bug as "Inherited From OOo".
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Tested again with Version: 18.104.22.168.alpha0+
Build ID: cfbb8b5090537e79ba70e250ddee86d53facbe15
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-10-18_22:54:20
Locale: de-DE (de_DE.UTF-8); Calc: group
on OpenSUSE 42.2.
Nothing changed in the buggy behavior.
Bug still exists in LO 22.214.171.124 64bit rpm Linux. Wrong date in a datefield of a form changes to value of current date. Could be somebody had implemented this to get the current data as default-value to this form-field. Have tested this - will work well! But if there is somebody who will fix this bug I can't use this "trick".