Bug 127252 - Priority ordering of conditional formatting in Calc as proposed in Bug 74074, Comment 19, does not work
Summary: Priority ordering of conditional formatting in Calc as proposed in Bug 74074,...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Conditional-Formatting-Editing
  Show dependency treegraph
Reported: 2019-08-31 12:51 UTC by marc.claes9
Modified: 2023-10-07 03:19 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

One unconditional formatting and three unconditional formattings added to range A2:Z55 (22.15 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-08-31 12:53 UTC, marc.claes9

Note You need to log in before you can comment on or make changes to this bug.
Description marc.claes9 2019-08-31 12:51:55 UTC
This is a follow-up on bug 74074 (on which I added comments 21 to 23 - but somewhat fumbled, I'm afraid... ;-)
I just installed v., and I noticed following effects:
Ordering of the conditional formatting priority, as set in the “Conditional” menu → “Manage...” item → “Edit...” pop-up window with the "Up"- and "Down"-button, is not honored. Apparently (but this has not been tested in further depth) "Colorscale"-types of conditional formatting seem to always have top priority.

Steps to Reproduce:
Please see attachment file "Cond_Form_Ex_20190815.ods", in which I added conditional formatting as well as normal formatting as follows (all formatting and conditional formatting is done to range A2:Z55):
1. the full range A2:Z55 is coloured yellow (unconditional),
2. columns between row 2 and row 55 are colored depending on their value between white (for minimum) and blue (for maximum) (do not be fooled by the progressive coloring of the rows – that is an effect of their progressive numbering, NOT of conditional formatting! The "Colorscale"-type cond. formatting is to the COLUMNS!),
3. any non-numeric or non-empty cells in the range are colored red,
4. any column between row 2 and row 55 is greyed when the cell in row 1 (of that column) is empty.

Actual Results:
grey has priority over red (see cell H52 and M52), but blue always has top priority…

Expected Results:
priority to grey, then to red, then to blue (see order in “Conditional” menu → “Manage...” item → “Edit...” pop-up window)

Reproducible: Always

User Profile Reset: No

Additional Info:
Additionally (but that is a feature request as well as a bug report...) when multiple conditional formats apply (even to different – but overlapping! - ranges), the order of priority of these should ALSO be changeable (with an “Up” and “Down” button in “Conditional” menu → “Manage...” pop-up window)!

Help - About LibreOffice info:
Build ID: 1:6.3.0-0ubuntu0.18.04.1~lo2
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 marc.claes9 2019-08-31 12:53:56 UTC
Created attachment 153778 [details]
One unconditional formatting and three unconditional formattings added to range A2:Z55
Comment 2 Mike Kaganski 2019-08-31 13:12:42 UTC
In essence: in columns D, G, H, L, M, P, Q, V, there should not be any cell colouring but grey, since that's what the first matching condition tells.

I confirm this to be broken (having blue cells with numbers in those columns) with Version: (x64)
Build ID: e979878b49a48dab15ebe528f238b88125e32c65
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

The feature request (about different conditional formats in possibly different overlapping ranges) must not be handled along with the bug report, so please file it separately, and ignore it here.

The part about #2 ("columns between row 2 and row 55 are colored ... do not be fooled by the progressive coloring of the rows") - this seems to be misunderstanding. The color scale conditional format does not differentiate between rows and columns; it is applied to the range as a whole, and it analyzes all the cells in the whole range to decide which value would get which color (e.g., put 2500 to Z53, and see that all other numeric cells in all rows/columns get ~white).
Comment 3 marc.claes9 2019-09-02 05:46:51 UTC
Thanks, Mike,

Indeed, the columns you list (as well as Z, but then I'm nitpicking... ;-) )

I'll file that 'feature request' separately and edit the title accordingly (remove the 'b)'-part), but give me some time; I'm learning as I go...

Thanks also for the lead on the colorscale formatting; I wasn't aware! One more thing I learned...
Comment 4 QA Administrators 2021-10-03 04:07:38 UTC Comment hidden (obsolete)
Comment 5 marc.claes9 2021-10-06 16:56:08 UTC

I tested the attachment (153778) with my installed version (see below); bug is still present, I'm afraid...


Version: / LibreOffice Community
Build ID: 20(Build:2)
CPU threads: 6; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Ubuntu package version: 1:7.2.1-0ubuntu0.20.04.1~lo1
Calc: threaded
Comment 6 QA Administrators 2023-10-07 03:19:31 UTC
Dear marc.claes9,

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