Description: When applying a conditionnal format, date data is displayed as a decimal number. Steps to Reproduce: 1.open the test file 2.look at red cells and see that the data inside is a date. 3. Actual Results: Wrong format Expected Results: Date format Reproducible: Always User Profile Reset: No Additional Info: Tested on Version: 7.2.2.2 / LibreOffice Community Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded works with Version: 6.2.8.1 Build ID: 815fe723fb0e60e4a39ff860f907cc63980a0232 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded doesn't work with Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded it works with Version: 6.1.4.1 Build ID: 25073d18caee244880112e52c4a7e71f6081b3a9 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk2; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded So regression is between 6.2.8.1 and 6.3.6.2
Created attachment 176601 [details] Test document ods
Version : 6.3.3.2 is not affected Version: 6.3.4.1 is affected Build ID: a21169d87339dfa44546f33d6d159e89881e9d92 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded So think the false commit is in this version.
Confirming with version: Version: 7.3.0.0.beta1+ / LibreOffice Community Build ID: 81b26582ed62db40e2be701ddefede7d8230d0d2 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded Seems to have started with: https://git.libreoffice.org/core/+/0b9e0f20763f0e723d66f31aee85205deec9f6f8 author Eike Rathke <erack@redhat.com> Sun Oct 27 00:25:28 2019 +0200 committer Caolán McNamara <caolanm@redhat.com> Wed Oct 30 18:04:18 2019 +0100 tree 519cc33af5493e8c97c750395919fd628f10c2da parent fe7deff845c39a351a92b8e01168a527fc237a9b [diff] Resolves: tdf#117715 Conditional format takes precedence; reverts tdf#93300 Adding CC to: Eike Rathke
Created attachment 176609 [details] The example document in 6.3 and 6.0.7 (good)
I can also reproduce with 7.3.0 Beta1. However, after examining the attached spreadsheet and reading the bibisected commit in comment 3, I'd like to argue that this is the result of an intentional change and expected behavior, and the user should change their document instead. The column J of attachment 176601 [details] has "Default" cell style, which doesn't seem to set the numbers format. So likely the column is set to "Date" format with direct formatting (didn't check the XML source to confirm). Then on top of it two conditional formatting are applied, one set to apply "cf110" cell style (green background), the other "cf111" (red background). Now if we look at the "cf110" and "cf111" cell styles closely, "cf110" has the numbers format set to "Date", the same as direct formatting; however "cf111" has the numbers format "Number", different from the direct formatting's "Date". Therefore after commit 0b9e0f20763f0e723d66f31aee85205deec9f6f8, the "cf111" conditional formatting takes precedence, overwriting direct formatting's "Date" format and displays "Number" format instead. Modifying "cf111" cell style and explicitly set numbers format to "Date" will get the same displaying result as pre-6.3.4. IMHO bug 93300 should be reopened and this can be marked as duplicate of that one.
Dear Regis Perdreau, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug