Bug 109280 - conditional formatting not preserved with copy paste operations
Summary: conditional formatting not preserved with copy paste operations
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.7.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 113370 (view as bug list)
Depends on:
Blocks: Conditional-Formatting Paste
  Show dependency treegraph
 
Reported: 2017-07-22 22:33 UTC by jtl
Modified: 2020-05-09 22:11 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
blood pressure log (33.03 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-22 22:33 UTC, jtl
Details
before inserting a row (168.59 KB, image/png)
2017-07-23 09:11 UTC, Xavier Van Wijmeersch
Details
after inserting a row (205.87 KB, image/png)
2017-07-23 09:12 UTC, Xavier Van Wijmeersch
Details
after inserting with LO dev 6.0 (180.91 KB, image/png)
2017-07-23 09:48 UTC, Xavier Van Wijmeersch
Details
Copy-Paste Conditional Formatting Bug (120.09 KB, application/vnd.oasis.opendocument.graphics)
2017-07-23 13:12 UTC, jtl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jtl 2017-07-22 22:33:03 UTC
Created attachment 134788 [details]
blood pressure log

This serious bug still exist in libreOffice-Calc v5.2.7.2 and v5.3.4.2

How to duplicate

using attached sheet
1) insert a new row below row 4
2) copy all of row 4
3) paste into empty row 5
4) save and close Calc
5) reopen calc, conditional-formating is lost, but text/values preserved 

Also be advised the bug did not exist in libreOffice-Calc v4.3.3.2

Note: our clinic depends on this functionality and it is costing us time and money having to copy each column value, one at a time...
Comment 1 tommy27 2017-07-23 07:03:54 UTC
please post some screenshot showing the difference between that file in this 3 states:

1- before editing
2- after editing (end of step 3 of your description)
3- after saving and reloading (step 5 of your description)

please, also tell the exact O/S you are using.

according to your report the bug is present in latest 5.3.4.2 and not in 5.2.7.2

you said it's not present in 4.3.3.2... was is a typing error and you meant 5.3.3.2?

where exactly the regression appear? between 5.2.7 and 5.3.4 or between 5.3.3. and 5.3.4?

did you try resetting the 5.3.4 user profile (link: https://wiki.documentfoundation.org/UserProfile )

please give feedback.
status NEEDINFO
Comment 2 Xavier Van Wijmeersch 2017-07-23 09:10:34 UTC
I can confirm the behavior
In manage conditional formatting you can see the formatting is omitted, no c5
But when selecting all the cells and drag it down with the mouse to the next row, the formatting is copied down

Version: 5.3.4.2
Build ID: SlackBuild for 5.3.4 by Eric Hameleers
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 3 Xavier Van Wijmeersch 2017-07-23 09:11:43 UTC
Created attachment 134793 [details]
before inserting a row
Comment 4 Xavier Van Wijmeersch 2017-07-23 09:12:51 UTC
Created attachment 134794 [details]
after inserting a row
Comment 5 Xavier Van Wijmeersch 2017-07-23 09:48:11 UTC
Created attachment 134796 [details]
after inserting with LO dev 6.0

After copy/past the conditional formatting change to new entree
Its a old behavior from the past that i have seen a lot when a needed changing columns and rows in a project

Version: 6.0.0.0.alpha0+
Build ID: 8becd40f030b94fe3fb6ad82b048ee97daaea2b1
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 6 jtl 2017-07-23 13:12:21 UTC
Created attachment 134798 [details]
Copy-Paste Conditional Formatting Bug

This attachment shows each step to recreate the 
   conditional formatting not preserved with copy paste operations BUG
Pictures from top to bottom show
   1) sheet w/o any changes
   2) sheet after inserting row
   3) sheet after copying row 4 into row 5
     ** now the sheet IS SAVED and CLOSED
   4) sheet after re-opening Calc
     ** conditional formating is LOST
Comment 7 jtl 2017-07-23 13:16:05 UTC
To answer "tommy27" question, here is the following information. 

Version 4.3.3.2 is included in Debian 8.8 64bit and it works as expected.

Version 5.2.7.2 is included in Debian 9.0 64bit and 9.1 64bit. Note: when we updated to Debian 9.0 we noticed the bug, but held off reporting until 9.1 was released and yes we contacted Debian and they say its your issue!

Version 5.3.4.2 was installed on Debian 9.1 64bit from LibreOffice.flatpak, obtained at https://download.documentfoundation.org/libreoffice/flatpak/5.3.4/ and it still has the bug

Included the attachment 
    Copy-Paste Conditional Formatting Bug.odg
This attachment shows each step to recreate the 
   conditional formatting not preserved with copy paste operations BUG
Pictures from top to bottom show
   1) sheet w/o any changes
   2) sheet after inserting row
   3) sheet after copying row 4 into row 5
     ** now the sheet IS SAVED and CLOSED
   4) sheet after re-opening Calc
     ** conditional formating is LOST

We gave you a test sheet "blood pressure log", so there is NO reason you can not test and duplicate the bug.
Comment 8 tommy27 2017-07-23 13:24:13 UTC
@ jtl

thanks. so you noticed the issue for the first time in 5.2.7.2, and said it was working fine in 4.3.3.2

there has been a lot of major release between them... 

did  you have the chance to test LibO 4.4.x , 5.0.x and 5.1.x to see where the regression started?
Comment 9 tommy27 2017-07-23 13:37:49 UTC
@jlt
you put yourself in the "Assegnee" field which means you want to fix the bug by yourself.
I suppose it was an error... that field is supposed to be used by software developers
Comment 10 jtl 2017-07-23 14:15:12 UTC Comment hidden (off-topic)
Comment 11 Xavier Van Wijmeersch 2017-07-23 16:26:32 UTC
@jtl
In tools => options => libreoffice calc => general 
check the expand formatting; expand references; update references
it maybe helpful
did some new test and following your description, when reopen the file the formatting was not lost

Version: 5.4.1.0.0+
Build ID: 6622ea7365fbf1b425e5f90667dd7e6466fd0293
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-07-21_06:37:51
Locale: nl-BE (en_US.UTF-8); Calc: group

@Tommy
didn't notice that cc is for developers only
will not happen again
Comment 12 tommy27 2017-07-23 17:18:39 UTC
(In reply to jtl from comment #10)
> tommy27
> 
> No we do not want to fix the bug our self, that was a submission error.
> 
> Given the fact we (and others) have submitted detailed information on the
> bug and how to create it, you want to play around asking more stupid
> needless questions.
> 
> Sorry bud, as a business we do not have time for those games.
> 
> We truly hope you supervisors read this email chain and remove you a
> representative of libreOffice, because its clear you would rater play then
> fix the issue.


I'm not playing with you... I was just trying to teach you how this bug tracker works and how to use it...

now I realize you also need a good manner course.
shame on you.  thumbs down.
Comment 13 tommy27 2017-07-23 17:30:27 UTC
(In reply to Xavier Van Wijmeersch from comment #11)
> ...
> 
> @Tommy
> didn't notice that cc is for developers only
> will not happen again

no Xavier, the "CC List" filed is not a "developer only" field.
you don't have to remove yourself from there.

any user who wants to receive email notification with updates about this bug report may leave his name there (usually anytime you drop a comment in BugZilla you are automatically added to CC unless you change that default setting).

the "developer only" field is the "Assignee" field...
if you place your name there it means that you "take property" of the bug and you want to fix it.

but if someone who is not a developer erroneously puts himself into "Assignee" other developers won't work to fix it since they could think that there's somebody else already working on it.

so, basically this is how the bugzilla works...

removing "jtl" from the "Assignee" field where he wrote his name as as mistake, was necessary to leave this bug open for true developers who may try to fix it.

regarding me, I am not a developer but a QA volunteer that helps triaging bug reports and teach new user how to use the tracker.

so I'm sorry to tell to "jtl" that no supervisor will "kick me out" as "representative of LibreOffice" since I've exactly done what it was supposed to be done.

so, again learn how to use the bugtracker and don't be harsh with people that tries to teach you how to use things you clearly showed you don't know how they work.
Comment 14 MM 2017-07-23 18:45:37 UTC
With Version: 6.0.0.0.alpha0+
Build ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-20_22:42:49
Locale: en-US (en_US.UTF-8); Calc: single

formatting is lost when pasting, but it's there again when reloading.

> Given the fact we (and others) have submitted detailed information on the
> bug and how to create it, you want to play around asking more stupid
> needless questions.
> 
> Sorry bud, as a business we do not have time for those games.

As volunteers we don't like it when someone trying to force something w/ harsh words. If someone knows it better, then do it yourself or get some paid help.
Comment 15 Andreas Säger 2017-07-24 12:18:56 UTC
Yes, LO broke the conditional formatting. It behaves consistently but with old limitations in AOO.

Instead of applying the same c.f. 43 times to 43 rows you may try this:
Click C2 and call the c.f. editor.
At the bottom of that dialog expand the range from C2 to C2:C44.
Expand the c.f. in D2 to D2:D44.
Call the c.f. manager and delete all the c.f. that refers to a single cell.

For easier consistent list keeping, I recommend to install my Python macro https://forum.openoffice.org/en/forum/viewtopic.php?f=21&t=2350

And to be honest: Maintaining clinical data in spreadsheets is beyond any definition of quality managment. nobody would bother if I would do that at home (which I don't); doing so in an institution is scandalous.
Comment 16 raal 2017-07-28 16:20:43 UTC
This seems to have begun at the below commit.
Adding Cc: to Markus Mohrhard; Could you possibly take a look at this one? Thanks
 25e17f9fcfd4745e05c4861c3d728c5bea58fe94 is the first bad commit
commit 25e17f9fcfd4745e05c4861c3d728c5bea58fe94
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon Sep 19 10:34:28 2016 -0700

    source 3a9917b66d6820ec9f2844f8292a46d8b0b9180b
author	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-19 15:18:21 (GMT)
committer	Markus Mohrhard <markus.mohrhard@googlemail.com>	2016-09-19 15:19:40 (GMT)
commit 3a9917b66d6820ec9f2844f8292a46d8b0b9180b (patch)
tree f1615daafda8d2715fbf63056aaa842f4d199be2
parent c708c9351bf2ef578e2f200ee834731c31d80261 (diff)
tdf#100393, handle copying one cell to multiple cols with cond format
The same fix has been applied for rows already.
Comment 17 Buovjaga 2018-03-25 17:31:45 UTC
I get no problem now, please everyone re-test with the latest.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 54c2637c1c9b526ffd9423e2d8e431474b535276
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on March 25th 2018
Comment 18 Xavier Van Wijmeersch 2018-03-25 18:42:43 UTC
can be closed as fixed

Version: 6.1.0.0.alpha0+
Build ID: 7422687028d33a9a4029aeb9265bc59578f5aef9
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 19 Buovjaga 2018-03-25 18:52:19 UTC
We don't know the commit, so tweaking status.
Comment 20 eisa01 2020-05-09 22:11:47 UTC
*** Bug 113370 has been marked as a duplicate of this bug. ***