Bug 58988 - Copy and paste chart fails if the source sheet does not have the default name
Summary: Copy and paste chart fails if the source sheet does not have the default name
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta2
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Kohei Yoshida
QA Contact:
URL:
Whiteboard: bibisected40 target:4.1.0 target:4.0.0.2
Keywords: regression
Depends on:
Blocks: mab4.0 59335
  Show dependency treegraph
 
Reported: 2013-01-03 16:17 UTC by Jean-Baptiste Faure
Modified: 2016-05-20 15:39 UTC (History)
3 users (show)

See Also:


Attachments
bugdoc with chart on a renamed sheet (25.72 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-01-03 16:17 UTC, Jean-Baptiste Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Faure 2013-01-03 16:17:39 UTC
Created attachment 72462 [details]
bugdoc with chart on a renamed sheet

Steps to reproduce:
1/ open the attached bugdoc in LO 4.0.0.0.beta2
2/ be aware that the name of the sheet in which the chart is, is not the default name Sheet1
3/ select the chart and copy it
4/ paste the chart elsewhere on the same sheet
5/ now compare:
   5-a/ double click on the original chart, then right click -> you get "Data Range..." item in the contextual menu
   5-b/ do the same on the copy -> you get "Chart Data Table..." item instead of "Data Range...". AFAIK that means that, in this case, the chart is copied as an object embedding its data instead of copied with reference to data source.

6/ Now, remove the copy and rename the sheet to Sheet1 (or the default name in your configuration)
7/ redo steps 3, 4 and 5 -> you get "Data Range..." item for the copied chart.

You get the same behavior if you copy the chart to another sheet in the same file.
As a consequence you cannot move a chart from a location to another if you have renamed the sheets of your spreadsheet.

It is a regression because LO 3.6.4 works as expected: the chart is copied with reference to the same data as the original, whatever the sheet name is.

Best regards. JBF
Comment 1 Jean-Baptiste Faure 2013-01-03 16:21:43 UTC
Forgot to add that I found this problem in Version 4.0.0.0.beta2+ (Build ID: 2e340c01bb84cd215bfe4cc091a73756423f464)

Ubuntu 12.04 x86-64

Best regards. JBF
Comment 2 Michel Rudelle 2013-01-03 18:14:07 UTC
I confirm.
Correct operation is obtained with the default name only on the sheet number one (Sheet1) 
Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)
under Vista:
Comment 3 Markus Mohrhard 2013-01-04 19:38:49 UTC
I'll look into it.
Comment 4 Jorendc 2013-01-05 14:29:41 UTC
@Markus:

git bisect start
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00
# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262
# bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6
# good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc
# bad: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90
git bisect bad fb4214f9d134b556582a4a5280e5458de5f8eebd
# good: [e2e46267c18c2706de771a08472ebfce19f68520] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588
git bisect good e2e46267c18c2706de771a08472ebfce19f68520
# bad: [9a5620ca6473969359f262802c76daf35cbcbb5d] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
git bisect bad 9a5620ca6473969359f262802c76daf35cbcbb5d
Comment 5 Jorendc 2013-01-05 15:43:12 UTC
Because I didn't copy all the information from bibisect the first time, I did it overnew:


joren@Ubuntu-Joren:~/bibisect40$ git bisect bad
9a5620ca6473969359f262802c76daf35cbcbb5d is the first bad commit
commit 9a5620ca6473969359f262802c76daf35cbcbb5d
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Tue Dec 11 01:59:31 2012 +0000

    source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
    
    commit ae4e4a11d4300f7448cb6bd170fcb034542caddc
    Author:     Rene Engelhard <rene@debian.org>
    AuthorDate: Tue Nov 6 21:24:32 2012 +0100
    Commit:     Rene Engelhard <rene@debian.org>
    CommitDate: Tue Nov 6 21:24:32 2012 +0100
    
        typo...
    
        Change-Id: I2c7968194afbcf74967cd16c639dce7de858a513

:100644 100644 c09b92a8ddf24b8738a7cd3a695ae1e4482d354c 6b13afd13f023cedac65a896318de4aa55dead27 M	autogen.log
:100644 100644 bcee1e11bd693642ca5a6330175b58082e5dcdd0 54d2377f5b3afd6ed668b3e24cb877c289119ec5 M	ccache.log
:100644 100644 75677cef16786d2cc95c0d8f301482278ca055c3 d18a6ebcd3b8537c3dd3dbc16e862fb6370ecb8a M	commitmsg
:100644 100644 83b4ecc0ecb3e031c804d49f45f854e95d5cc961 d482c00e5fff6081c6b87b637fd9ffaf3e1e2c6c M	dev-install.log
:100644 100644 91437b9974ffada7e049273419bb8c66c91c0539 abf45ab9609c77a5ab952aa310eafe8c2ffaf85c M	make.log
:040000 040000 45c0bab8b669778ab523c8f65a25e8c9afde604a f4bfa15b2f72d3df5675b07bcf32254a819b9d19 M	opt



joren@Ubuntu-Joren:~/bibisect40$ git bisect log
git bisect start
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00
# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a
# good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c
git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9
# good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda
git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a
# good: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902
git bisect good 114fd3b76bcba890e6d702d00cef910f1493c262
# bad: [47498a36f7af8f54e6e3dda89cd4708802a409e6] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
git bisect bad 47498a36f7af8f54e6e3dda89cd4708802a409e6
# good: [f4e2d84db194943180f3e7ed4adce5f8e377d9bc] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10
git bisect good f4e2d84db194943180f3e7ed4adce5f8e377d9bc
# bad: [fb4214f9d134b556582a4a5280e5458de5f8eebd] source-hash-683758efb22d08a4cf211a6d985148f513da2a90
git bisect bad fb4214f9d134b556582a4a5280e5458de5f8eebd
# good: [e2e46267c18c2706de771a08472ebfce19f68520] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588
git bisect good e2e46267c18c2706de771a08472ebfce19f68520
# bad: [9a5620ca6473969359f262802c76daf35cbcbb5d] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
git bisect bad 9a5620ca6473969359f262802c76daf35cbcbb5d
Comment 6 Markus Mohrhard 2013-01-05 23:17:51 UTC
Ok, this is another bug being introduced by the rebase.

I have a suspect for the regression and I already know why we change to an internal data provider, I just need to find the righ line in the import/export code being responsible for this regression.
Comment 7 Kohei Yoshida 2013-01-17 03:22:26 UTC
I'll take this over.  I have a preliminary fix which seems to work well all around.  The same fix also fixes Bug 58562 as well, and possibly others.
Comment 8 Kohei Yoshida 2013-01-17 04:55:38 UTC
Nevermind.  My fix was still premature.  Back to the drawing board.
Comment 9 Not Assigned 2013-01-18 19:44:33 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c55d52262ea1d5f869a9528fd051ee19e687f1cc

fdo#58988, fdo#58562: Populate draw clip document with data for charts.



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.
Comment 10 Jean-Baptiste Faure 2013-01-18 20:09:09 UTC
Hi Kohei

Thank you very much for the quick fix! 
Do you plan to backport it to 4.0.0 ?

Best regards JBF
Comment 11 Kohei Yoshida 2013-01-18 20:10:37 UTC
(In reply to comment #10)
> Hi Kohei
> 
> Thank you very much for the quick fix! 
> Do you plan to backport it to 4.0.0 ?

Yes, I'm working on it.
Comment 12 Not Assigned 2013-01-21 20:24:01 UTC
Kohei Yoshida committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ecb30cede30fea5a6a239d3d8da8ebbf8b79bf9&h=libreoffice-4-0

fdo#58988, fdo#58562: Populate draw clip document with data for charts.


It will be available in LibreOffice 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.
Comment 13 Kohei Yoshida 2013-01-23 14:58:59 UTC
Ok.  The next 4.0 build that contains the above fix should resolve this case.  I'll close it as fixed.

Note: I'm not sure if this has made it into the 4.0 final (the fix was rather late).
Comment 14 Jean-Baptiste Faure 2013-01-24 08:37:07 UTC
Verified in Version 4.0.1.0+ .1.0 (Build ID: a6433b4a9c053b7088d52b216c7d7cf8d9cdfcd) under Ubuntu 12.04 x86-64
Verified in LibreOffice 4.0.0.2 (RC2) under Ubuntu 10.04 x86

Nota: when copying data + chart from a file to another, the link between the data and the chart is kept if they are pasted in a sheet having the same name as the origin sheet.

(In reply to comment #13)
> [...]
> Note: I'm not sure if this has made it into the 4.0 final (the fix was rather late).
Yes it is : http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-0-0&id=1ecb30cede30fea5a6a239d3d8da8ebbf8b79bf9

Thank you very much for the fix.

Best regards. JBF
Comment 15 Kohei Yoshida 2013-01-24 12:51:22 UTC
(In reply to comment #14)

> Nota: when copying data + chart from a file to another, the link between the
> data and the chart is kept if they are pasted in a sheet having the same
> name as the origin sheet.

That's also a bug I just fixed in Bug 58562 (the second fix).  When copying a chart from one doc to another, it should never keep the original range references.