Description: When duplicating sheets, or when coping the full contents of a sheet into another one, the conditional formattings get corrupted. Steps to Reproduce: 1. Create 3 conditional formattings, colour scale with default values, one for column A, other for column B and a last one for column C. 2. Right click sheet and select "Duplicate Sheet" Actual Results: The new sheet doesn't maintain the conditional formattings properly and only has one conditional formatting. When going to Conditional > Manage in the new sheet we see one conditional formatting: - A1:C1048576 Expected Results: The new sheet should maintain the 3 different conditional formattings as in the original sheet. When going to Conditional > Manage we should see 3 conditional formattings: - Range A1:A1048576 - Range B1:B1048576 - Range C1:C1048576 Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-IE (en_IE); UI: en-GB Calc: CL threaded
Created attachment 196764 [details] Original sheet
Created attachment 196765 [details] Duplicated sheet (Right click on original sheet > Duplicate sheet)
Please attach a sample file, reduce the size as much as possible without private information.
Created attachment 196777 [details] Sample file
Sample file attached, issue can be replicated duplicating Sheet1. Sheet1_2 is a duplication of Sheet1 where the issue is present. I have tested and this issue happens in two of my machines, one running Windows 11 and LibreOffice 24.8.2.1 and other running Fedora 40 and LibreOffice 24.2.2.1.
This happens because of the forced imposed unification of CF, which not always is desired, and sometimes the result is not equivalent to the original multiple CF conditions (as in this case). The unification of CF should not be forced, but manual. The user, when interested, should be able to select specific lines of the CF manager, and then press some button in the UI in order to attempt to unify several CFs. If a possible (partial) unification can happen on the previously-selected CF lines/rules, only then such unification should be applied (and when the selected CF lines cannot be unified, then the specific lines that cannot be unified should remain as-is). IOW, the unification should not be automatic and forced, but manually selected by the interested user. The current unification algorithm might remain the same (at least as a first approach), and users won't be forced to delete and rebuild the whole CF anew. The user would have control, instead of getting the unintended result (and having to rebuild it/them by hand).
@Ady, agree, but a better description in title could help to get it solved.
(In reply to m_a_riosv from comment #7) > a better description in title could help to get it solved. As a bug report, the Summary seems at least accurate. As a request (for enhancement) to actually solve the problem (not just for this case) by transforming the forced automatic unification to a manual unification of CF on selected CF items, probably Heiko and relevant devs should rather propose a more adequate Summary, depending on how they plan to solve the problem.
I experience a related issue on Debian, with conditional formatting with the clause "is duplicate". On Calc, I have a sheet where I wanted to use CF to visually notify when I have a duplicate entry. So on my sheet, all the (relevant) cells share the set of possible values, and in each column I do not want any duplicate. I create several "if is duplicated then format as Bad" (one per column), and it worked well. However, if I duplicate the sheet, or the duplicated sheet the formatting rules are all merged in a single one with all the domains (i.e., all the columns) merged. This results in not having any duplicate at all instead of not having duplicate per column. Similarly, but I'm not sure when, either when I saved and loaded or when I added more CF rules, I ended up losing the per column rules in the original sheet as it got all merged in a single "if is duplicate". The steps to replicate are very easy : 1. create new document 2. add "is duplicate" rule to domain a1:a10 3. add "is duplicate" rule to domain b1:b10 4. duplicate the sheet 5. in the new sheet, the domains are merged I think, contrary to what is proposed by the original bug reporter, the issue is deeper than just asking for a merging button in the UI, but can be also addressed more quickly. Not all rules are to be evaluated in the same way. For most of the rules, the evaluation only depends on the cell's value and the domain only specify which cells are to be considered. For "is duplicate" and "is not duplicate", the domain is also considered when evaluating the rule, and therefore merging domains is not possible without changing meaning of the rule. The issue is similar when considering heatmaps or colour scales applied to a domain. I believe the most elegant solution would be to add a boolean to the different CF operations, which would specify if the domain only specifies where to apply the rule (i.e., for rules where only the value of the cell matters), and where the domain is also part of the evaluation of the CF (i.e., for "is duplicate", "is not duplicate", "above/below avg", etc). In the former case, the merging is not affecting the evaluation and can be kept. In the latter, the merging of domains should be disabled because it actually is erroneous.
*** Bug 167019 has been marked as a duplicate of this bug. ***
Hi Francisco, this issue looks like a duplicated of bug 162692, please upgrade LibreOffice to the latest 25.2.4.3 where this issue should be fixed. *** This bug has been marked as a duplicate of bug 162692 ***
Hi Xisco, I just installed 25.2.4.3 (deb, downloaded and installed from libreoffice.org, Last modified: Fri, 06 Jun 2025 06:59:24 GMT (Unix time: 1749193164)) and the issue I raised is still present: erroneous merging of domains when duplicating the sheet. This leads to a modified domain, and therefore a modified ensemble to consider when looking for duplicates, highest/lowest N values, above/below AVG, etc. Thus the CF formula becomes erroneous and the expected result is no more valid. Best regards,
(In reply to Clément FOYER from comment #12) > Hi Xisco, > > I just installed 25.2.4.3 (deb, downloaded and installed from > libreoffice.org, Last modified: Fri, 06 Jun 2025 06:59:24 GMT (Unix time: > 1749193164)) and the issue I raised is still present: erroneous merging of > domains when duplicating the sheet. > > This leads to a modified domain, and therefore a modified ensemble to > consider when looking for duplicates, highest/lowest N values, above/below > AVG, etc. Thus the CF formula becomes erroneous and the expected result is > no more valid. > > Best regards, Could you please explain the steps to reproduce it ? At least in my case, I can't reproduce it with these steps: 1. Open attachment 196777 [details] 2. Duplicate sheet 1 The conditional format is the same in sheet 1 and in the new created sheet Version: 25.2.5.0.0+ (X86_64) / LibreOffice Community Build ID: 2f108c6a2bed0557ddf625f82c6d548645b24599 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded