Description: Conditional formatting shouldn't be merged when moving columns with conditional formatting to side by side. Only when 2 conditonal formattings having the same conditions (colors), they are merged. Steps to Reproduce: 1. Open attached example file 2. Select column C 3. Move column C to column B (overwrite column B or add it between A and B - same result) Actual Results: The existing conditional formatting of columns A and column B are merged, resulting in useless colors of the conditional formatting. See the manager of conditional formatting: only 1 entry exists anymore with the range A1:B1048576. Expected Results: The existing conditional formatting of columns A and column B are remaining independent of each other, resulting in correct colors of the conditional formatting. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 43fc662520e5488cbeadd6eb60a24374a837dca4 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Created attachment 198740 [details] Example file
See also: bug 158187 comment 4.
https://gerrit.libreoffice.org/c/core/+/180735 Let me post the current commit message, because it is not as simple as just disabling deduplication for the specific CF types: === The conditional formats like colorscale, databar and iconset may take their whole range to calculate their maximum / minimum, and each cell format would depend on the CF range. Thus, automatic merge of ranges of similar CFs when copying/pasting could create unexpected results. E.g., merging CFs of two distinct color scales - one for a range from 1 to 10, and another from 100 to 500 - would change colors on both of them, which is usually not what user wants, even when these ranges are side by side in adjacent columns. On the other hand, users still may want to have a way to expand the range automatically. E.g., when there is a column from A1 to A10 with a colorscale, and the user copies a cell from that range to A11, it is very likely that the intention is to expand the existing CF, not to create a separate colorscale individually for the cell A11. This makes it necessary to create some complexity in deciding when to deduplicate, and when not. This change introduces a function for that, called isRangeDependentFormatNeedDeduplication; and implements some simple algorithm that currently only depends on analysis of the two CFs' ranges. If both ranges are one-dimensional vectors, and the new CF range "continues" the existing range (the edges of the two vectors are adjacent), then it decides to combine them into one expanded CF. Also, if the new range is completely inside the old one (which may easily happen, when a user copies a cell from one place to another inside the same range), it also allows deduplication. In other cases, it rejects deduplication, requiring creation of a new CF. It may be extended as needed. One possible improvement could be e.g. when a user has a two-dimensional colorscale block, and copies some of its rows below, then it would be likely that the intention is to expand the range of existing CF, rather than creating a new one for the expanded range. This would need some specification how to tell this case from others that must not deduplicate. I must note that this problem is indeed difficult: e.g., in Excel, there is also no simple logic around copying such CF. I saw very odd cases, where the copy resulted in merging ranges of existing CF, or in creation of new CF; also, it could even magically add cells to existing CFs without copy - just by entering data below existing CF (and even when there was some gap between the existing CF range and the newly entered data - but not when there was two gaps). So there likely will always be some corner cases where users expect something else. This changes the behavior established in commits 3f614f431475e1bf3bb3bbeac59b0681309628b7 (tdf#95295: don't add duplicate conditional formats, 2017-12-11), 3fa15dd614bd72ddb36dbe033abeef5609d31f38 (tdf#154906 tdf#129813 tdf#129814 sc: fix conditional format color scale, 2023-04-26) and 8af6c46a9c0e86bbbd908e96ff236ad1d6c4ddab (tdf#155319 sc: fix conditional format data bar after copying, 2023-05-22) regarding the mentioned types of CF.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2d1acf7dd0558f5c2575cef58df7db4e59181a68 tdf#164844: handle colorscale and friends specially when deduplicating CF It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested, now this works as expected. Thanks. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f8a5594694c5f2861648c36ff7c87a21422f283 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/2274742b1d5a5340e64915f9343b7431fb374c69 tdf#164844: handle colorscale and friends specially when deduplicating CF It will be available in 25.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.