Bug 122907 - FORMATTING Style not correctly applied at conditional formatting
Summary: FORMATTING Style not correctly applied at conditional formatting
Status: RESOLVED DUPLICATE of bug 103793
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.1.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Shubham
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Conditional-Formatting
  Show dependency treegraph
 
Reported: 2019-01-23 18:32 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2019-10-27 10:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document to demonstrate the bug (10.92 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-01-23 18:32 UTC, Stefan_Lange_KA@T-Online.de
Details
modified test document - see Comment 4 (13.50 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-01-25 21:58 UTC, Stefan_Lange_KA@T-Online.de
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2019-01-23 18:32:33 UTC
Created attachment 148570 [details]
Test document to demonstrate the bug

Styles with at least date formatting are not correctly resp. completely applied at conditional formatting:
- font, alignment and background color are applied
- date format is not applied

To demonstrate the bug I have attached the document "Test_bedingte_Formatierung_Format_Datum.ods".

In the cells of column A I have entered two date values (01.01.1958 and 02.01.1958) and one text ("kein Datum").
For the cells is defined a conditional formatting with 3 conditions:
1. When day and month both are 1, only the year should be dislayed (style defined: Datum_jjjj).
2. When day and month not both are 1, the date should be dislayed as dd.mm.yyyy (style defined: Datum_tt-mm-jjjj).
3. When an error occurs also style Datum_tt-mm-jjjj should be applied.

Expected result (as shown in column C - styles appled without conditional formatting):
- The date 01.01.1958 should be displayed as 1958.
- The date 02.01.1958 should be displayed as 02.01.1958.
- The text "kein Datum" should be displayed as "kein Datum".

Actual results with LO from 3.3 until 5.1.1.3: as expected -> OK
Actual results with LO from 5.1.2.2 until 6.2.0 rc2, LOdev 6.2.1 and 6.3.0 alphy: the date format from style is ignored and both dates are dsplayed in a default format, e.g. dd.mm.yy.
Comment 1 Stefan_Lange_KA@T-Online.de 2019-01-23 18:39:25 UTC
Correction: The bug didn't occur in LO 5.1.2, but first in LO 5.1.3.2.
Comment 2 m_a_riosv 2019-01-24 00:08:15 UTC
The issue happens because the cell has a direct format, and if I'm not wrong CF respect them.

BTW there are a bit complicate formulas for the CF, if you go to A2 and set the firsts formula 'AND(DAY(A2)=1;MONTH(A2)=1)' it should work. The matter here it's go to the first cell of the CF's range, so relative ranges works properly.
Comment 3 Timur 2019-01-24 17:05:05 UTC
Stefan, please look at Bug 93300 and see if this Bug 103793 or Bug 117715.
Comment 4 Stefan_Lange_KA@T-Online.de 2019-01-25 21:57:32 UTC
The subjcect of Bug 122907 corresponds the subjects of Bug 117715 as well as Bug 103793 and is the opposite of Bug 93300 - seems Bug 122907 and both other are the result of the solution of Bug 93300, introduced with LO 5.1.3 (Markus Mohrhard). This build I had also found in my tests as first build with the bug.
If the solution of Bug 93300 is good or not - I don't know. As I see in the comments to the other bugs there are different views on the problem (e.g. the proposal "Another option would be to lock or unlock the properties of a style." in Bug 93300).
 
According to the hint of m.a.riosv I have deleted in my test document the direct formatting of column A via "Clear Direct Formatting" (conditional formatting was deleted too - OK or not?) and after I have re-defined the conditional formating the styles were applied correctly. On this way I could solve my problem. 
The only downside is that now the autofilter absolutely can't be used. With the behavior until LO 5.1.2 the autofilter by date could be used good when cells had direct formatitng as date and only the cells formatted as yyyy were displayed in the filter entry list as "not readable" numbers.

But I have made further tests and as result I have found different resp. inconsistent behavior depending on how conditional formatting is defined:
Seems conditional number formattig is overriden by direct number formatting only when the condition is defined for an area of cells. When the condition is defined for a single cell the number format of style applied because of the condition overrides the direct formatting.

To demonstrate this I have created "Test_bedingte_Formatierung_Format_Datum_V2.ods" as modified version of "Test_bedingte_Formatierung_Format_Datum.ods":
- column A: direct formating as date dd.mm.yy, conditinal formatting defined for area A2:A4 -> date format from direct formatting is used
- column B: direct formating was cleared and conditinal formatting re-defined for area B2:B4 -> date format from conditional formatting is used
- column C: direct formating as date dd.mm.yy, conditinal formatting defined for single cells C2, C3 and C4 (with "simple" formulas) -> date format from conditional formatting is used --> OK or not?
- column D: direct formating as date dd.mm.yy, conditinal formatting defined for single cells D2, D3 and C4 (with "complicate" formulas) -> date format from conditional formatting is used --> OK or not?
- column E: no conditional formatting, styles were applied explicitly to show what I wish to the by the conditional formatting
Comment 5 Stefan_Lange_KA@T-Online.de 2019-01-25 21:58:51 UTC
Created attachment 148666 [details]
modified test document - see Comment 4
Comment 6 Timur 2019-02-18 13:25:06 UTC
Sorry for not going into examples, but I'd rather mark this one as a duplicate of one of those two - and if assigned that you check the solution with your examples.
If you agree, please mark. If not, please explain what here is not covered with those.
Comment 7 Stefan_Lange_KA@T-Online.de 2019-02-18 19:11:37 UTC
I could declare Bug 122907 as a duplicate of Bug 103793, because it describes nearly the same problem, but that's not all.
Because I have found in my further test a different behavior depending on how conditional formatting is defined (see Comment 4), I think it would be better to retire Bug 122907 and to report a new bug with the different behavior as subject.
Would this be OK?
Comment 8 Timur 2019-02-19 08:50:18 UTC
I'd rather close this one as a duplicate and ask you to write differences there. 
We get fewer bugs with more details. 
Should that one be fixed and issues remained, it's easy to open this one again and write some current status.
Comment 9 Xisco Faulí 2019-06-26 09:52:33 UTC
Let's close it as a duplicate then...

*** This bug has been marked as a duplicate of bug 103793 ***