Download it now!
Bug 134307 - Tracking changes creates an entry for every change (so pasting a column means an entry for every cell)
Summary: Tracking changes creates an entry for every change (so pasting a column means...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2020-06-25 17:53 UTC by Telesto
Modified: 2020-06-30 14:36 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-25 17:53:49 UTC
Description:
Tracking changes creates an entry for every change (so pasting a column means an entry for every cell)

Steps to Reproduce:
1. Open attachment 161647 [details]
2. Edit -> track changes -> record
3. Copy column A-C and paste at EFG
4. Edit -> Track and changes -> Manage 

Actual Results:
Every cell has it own entry in tracking changes

Expected Results:
Paste seen as a single action, similar to undo. However Excel does this too.. 


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-06-25 18:01:03 UTC
I really have no clue how this should work. From performance point of view I would opt for a single entry, instead of every cell. Dialog 'manage' opens quite slow because of the long list of entry's

And when inserting/deleting a row it's only one entry, too.. 

OTOH, this is bit of an abuse of the tracking change feature.. So not a bug.. or a reason to make it a single entry
Comment 2 Heiko Tietze 2020-06-29 09:55:44 UTC
In Writer, pasting a whole table is one entry while a column is split into cells. With Calc it's always a per-cell TC. 

I agree that copy/paste actions should be considered as a whole for TC as done with the undo stack.
Comment 3 Eike Rathke 2020-06-29 11:50:10 UTC
No, it shouldn't. Or rather, it could in this one special case only if the target range was empty. As soon as existing data is replaced by the paste at least those individual values and changes must be tracked. So while splitting the paste into blocks of empty and non-empty target ranges might be a solution, tracking the empty target blocks would yield just a "here is a block of pasted data". If those then before empty cells contained data before which was cleared before pasting, going back in history to pick an older value would have to split that one block again. Same if a value in a pasted range is changed later. While all this may be doable it would quite complicate the tracking and the dependencies of changes.
Comment 4 Telesto 2020-06-29 11:53:25 UTC
(In reply to Eike Rathke from comment #3)
> No, it shouldn't. Or rather, it could in this one special case only if the
> target range was empty. As soon as existing data is replaced by the paste at
> least those individual values and changes must be tracked. So while
> splitting the paste into blocks of empty and non-empty target ranges might
> be a solution, tracking the empty target blocks would yield just a "here is
> a block of pasted data". If those then before empty cells contained data
> before which was cleared before pasting, going back in history to pick an
> older value would have to split that one block again. Same if a value in a
> pasted range is changed later. While all this may be doable it would quite
> complicate the tracking and the dependencies of changes.

Valid point.. FWIW.. excel does the same thing.. so not even sure if this 'broken' .. maybe the perf side of this should be tackled... someday
Comment 5 Eike Rathke 2020-06-29 11:58:42 UTC
Note I'm not against such a change, just to state that it's not as simple as it may look from first glance. It probably would also be needed to introduce such new feature to ODF and older releases wouldn't be able to read it. And it couldn't be exported to Excel..
Comment 6 Heiko Tietze 2020-06-30 12:48:41 UTC
(In reply to Eike Rathke from comment #3)
> No, it shouldn't.

What a pity. So let's resolve as WF.
Comment 7 Telesto 2020-06-30 14:36:26 UTC
(In reply to Heiko Tietze from comment #6)
Not sure if this fully in line with Eike his comment.. 
"Or rather, it could in this one special case only if the target range was empty."

OTOH a lot of effort, for something trivial..