Problem description: If I need to change the order of conditions in conditional formatting i have to rewrite many of them Steps to reproduce: 1. create two or more conditions in conditional formatting, save 2. try to change their order 3. .... Current behavior: not possible (to my knowlege) Expected (wished) behavior: drag'n'drop or up/down arrows icon should change the order of conditions Operating System: Windows 7 Version: 4.1.4.2 release
A very useful option.
*** Bug 74082 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Problem description: > If I need to change the order of conditions in conditional formatting i have > to rewrite many of them > Steps to reproduce: > 1. create two or more conditions in conditional formatting, save > 2. try to change their order > 3. .... > > Current behavior: > not possible (to my knowlege) > Expected (wished) behavior: > drag'n'drop or up/down arrows icon should change the order of conditions > > Operating System: Windows 7 > Version: 4.1.4.2 release Hi, a very useful request. Current workaround (very extensive): - Adding a new empty condition with EXTRA-button. - Copying previous conditions one by one to new position. - Editing the condition to be inserted. OS: Linux Ubuntu 14.04 i386/32bit LO-Version: 4.2.4.2 release
hi This improved Conditional Formatting seems very important to me. The order of priority different conditions is fixed for the moment. Having the ability to add a condition to any place or be able to move around its conditions would allow users to work faster and smarter. cordially Of French to English translation with Google
*** Bug 90060 has been marked as a duplicate of this bug. ***
> Current workaround (very extensive): > - Adding a new empty condition with EXTRA-button. > - Copying previous conditions one by one to new position. > - Editing the condition to be inserted. This not work correctly, sometimes newly added conditions adds not to end of old conditions, but in middle :( So I vote for adding interface for re-order condition in libreoffice caclc conditional formatting interface
And example with easy demonstrating the problem from Bug 90060: If first rule "greater than 5" apply Style "Red color", and second rule "greater than 10" on same cell apply Style "Green color" - all cells less than 10 and less than 5 will have Green color. This can be solved via change rule order, but there are no good way to change it.
*** Bug 90784 has been marked as a duplicate of this bug. ***
Deeply sorry for it but without the possibility to prioritize conditional formatting this feature is almost useless. IMHO, if we want to draw people away from Excel this should be fixed asap. In my case, even with a strong inclination to use Calc whenever possible and even when it sometimes is not as user friendly as Excel, this is a stopper for serious use. Having said this, I am aware of the effort many people are putting into LO and you are doing a great job (huge thanks)but we must sate things as they are...
As mentioned in my duplicate bug report, "As conditional formatting is applied based on the condition number in the sequence, we need 'Move Up' and 'Move Down' buttons next to the 'Add' and 'Delete' buttons so a user doesnt have to remove and re-add an entry to change the sequence ordering." This is primarily needed in the conditional formatting management dialog (sc/uiconfig/scalc/ui/condformatmanager.ui) and entries in the dialog shouldnt be sorted alphabetically rather than how they were added into a document (bug 91654), but also needed in the conditional formatting dialog (sc/uiconfig/scalc/ui/conditionalformatdialog.ui) so that individual rules can be managed.
Migrating Whiteboard tags to Keywords: ( needsDevEval topicUI) [NinjaEdit]
one more vote for this both inside a specific formatting and the list of ranges. LO used to sort the main list by range but no longer does making it difficult to locate the range to be edited.
Same as all of you guys. Fastidious to rearrange the order of conditions. Despite the fact that Libre office has my favors, this is a THUMB DOWN for it.
Manfred Blume committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a95e2a2bbdd1b95d97d3e79b1ef0bc5da95a110 tdf#74074 Ability to rearrange order of conditions It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks @Manfred, I think a lot of people will appreciate it. Tested with Version: 5.4.0.0.alpha0+ Build ID: 2f7b05988e6853ddac68b614e9d83e05af08bc0f CPU threads: 4; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2017-04-08_00:27:58 Locale: es-ES (es_ES); Calc: CL Should not be solved as fixed? Can it backported to 5.3?
> Should not be solved as fixed? Resolving accordingly > Can it backported to 5.3? The bugfix unfortunately involves UI & translatable string change, which excludes the possibility of backport [1]. Sry about that ... [1] unless one has L3 support and some1 also backports related translations for them
(In reply to Katarina Behrens (CIB) from comment #16) > The bugfix unfortunately involves UI & translatable string change, which > excludes the possibility of backport [1]. Sry about that ... > > [1] unless one has L3 support and some1 also backports related translations > for them Forgive me for an inadequate request.
I have just updated LO to Version 5.4.6.2 (x64), but in CALCs Conditional Formatting management dialog I can't find a possebility to change the order of the rules. No clickable arrange buttons, no drag & drop an no cursor keys. Did Manfreds patch make it into the 5.4.x releases? Cheers Andreas
Created attachment 140862 [details] Screenshot on 5.4.5 Find attached an screenshot for 5.4.5. There are the buttons New Delete Up Down
Thanks a lot Miguel! I expected the buttons within the manage dialog and did not see, that it's possible to add multiple rules within one section. Mea culpa! And as I tested: The list order represents the priorisation of the rules. The topmost matching rule will be used (if condition is matched). May be it would be a good idea to advise the users, that the rules in the list are not processed from top till down, as I first thought. Nice weekend to all! :-) Cheers Andreas
Created attachment 153411 [details] .odf example file for actual Conditional Formatting Priority effects
(I hope I didn't add the example at the wrong moment... Sorry.) I just installed v. 6.3.0.4, and I noticed following effects: * conditional formatting has priority over unconditional – as expected, * 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!) * any non-numeric or non-empty cells are colored red, * any column between row 2 and row 55 is greyed when the cell in row 1 (of that column) is empty. The intent is: priority to grey, then to red, then to blue (see order in “Conditional” menu → “Manage...” item → “Edit...” pop-up window) Obviously that is not honored: grey does have priority over red (see cell H52 and M52), but blue always has top priority… Additionally, I believe priority should be alterable at at least one more level: 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)!
Grmpf! Managed to get it all jumbled up! Sorry for the mess... What I wanted to add was: thanks for 6.3. At have to work with MS Office 365 at work, and that is slowly evolving into molasses... Your work makes LO slowly but shurely coming on par with MSO! Thanks again! Marc
Created attachment 157007 [details] conditions - edit mask screenshot this is the first mask that appears when editing conditions
Created attachment 157008 [details] editing condition - mask 2 - only current condition is listed this is the following mask "edit contidion" where the buttons up and down should rearrange the conditions' order. But only the selected condition is listed, so nothing to rearrange
Hi, I don't know if this is to file as a new bug: when I'm in the conditions editing mask (the one with the buttons up and down to rearrange the condition's order) I have not the complete liist of conditions, but only the one that I selected to edit. see attachments: https://bugs.documentfoundation.org/attachment.cgi?id=157007&action=edit and https://bugs.documentfoundation.org/attachment.cgi?id=157008&action=edit Versione: 6.3.4.2 (x64) Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa Thread CPU: 8; SO: Windows 10.0; Resa interfaccia: GL; VCL: win; Versione locale: it-IT (it_IT); Lingua interfaccia: it-IT Calc: threaded
hello boicottms@yahoo.it, This bug has been in RESOLVED FIXED status for more than 6 months. If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if needed, the steps and documents to reproduce it. Thanks for your understanding and collaboration. Closing as RESOLVED FIXED
Read me. It's worth it. *NOT FIXED* I don't think that this bug is fixed. At best, a rare sub-set of the issue was fixed. The original intent of this bug was to add the ability to "change the order of conditions" and "create two or more conditions in conditional formatting". There's no mention of rearranging only the conditions within the exact same range of cells. It's clearly about ALL conditions. *SIMPLIFIED EXAMPLE* Note: Row 1 contains the TITLES of the columns. Range: A2:H9999 / Condition: $A2<>"" / top & bottom border = pale-blue --> Nice "table" formatting that "grows" with more data-rows Range: G2:G9999 / Condition: $G2>200 / background = light-green --> Highlights interesting values *WHAT WENT WRONG AND WHY* LibreOffice (incomprehensibly) forcibly orders the conditions by the letter of the cell-column in the "Range". Therefore, the condition for Range "A2:H9999" will ALWAYS be above the condition for the Range "G2:G9999" (A is before G). *The formatting in a Rule that is below another Rule will ALWAYS override the formatting in the Rules above it.* There's no way to rearrange these conditions. In my example above, any cell that receives the light-green background will lose the top+bottom border. *This cross-contamination of Conditional Format rules affects all rules that have non-identical but overlapping Ranges.* Since it is quite possible that one rule is more important than another, and if its Range starts in a column with a letter further to the FRONT of the alphabet, it will unfortunately ALWAYS be overwritten by the less important Rule whose Range starts in a column with a letter further to the BACK of the alphabet. *THE STYLES PROBLEM - MAKING THINGS WORSE* The inability to sort conditions is made even worse by LibreOffice's inability to set any parts of a Style as "do not touch this sub-part of the formatting" (e.g. Don't touch Borders - i.e. make the background light-green, but do not overwrite the pale-blue border. Excel is able to do this, IIRC. *THREE PATHS FORWARD* To make LibreOffice's Conditional Formatting not an eternal exercise in frustration, at least one of the following paths needs to be chosen: 1. Reopen this bug until it is actually fixed (i.e. ability to rearrange top-level Conditional Formats). 2. Create a new bug or name an existing bug for rearranging the top-level conditions. 3. Create a new bug or name an existing bug to make it possible to set any parts of a Style as "do not touch this part of the formatting". My vote is for #1 and #3. :-) I'd be grateful for any pointers those bug numbers.
I found two bugs that attempt to add the ability to rearrange the top-level conditions (they call these "outer" conditions): bug 126047 and bug 148154. I was not able to find a bug to make it possible to set any parts of a Style as "do not touch this part of the formatting".