Bug 62057 - : Copying of diagram: categories and y axis interchanged in Calc
Summary: : Copying of diagram: categories and y axis interchanged in Calc
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: Other Linux (All)
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard: BSA bibisected40 target:4.2.0 target:...
Keywords: regression
: 66455 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-09 12:27 UTC by opensuse.lietuviu.kalba
Modified: 2014-07-30 15:32 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Diagram to be copied (150.38 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-03-09 12:27 UTC, opensuse.lietuviu.kalba
Details
Distorted diagram (61.62 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-03-09 12:30 UTC, opensuse.lietuviu.kalba
Details
Good diagram in Writer (61.67 KB, application/vnd.oasis.opendocument.text)
2013-03-09 12:30 UTC, opensuse.lietuviu.kalba
Details
Image of good (72.25 KB, image/png)
2013-03-09 12:36 UTC, opensuse.lietuviu.kalba
Details
Image of bad diagram (57.29 KB, image/png)
2013-03-09 12:37 UTC, opensuse.lietuviu.kalba
Details

Note You need to log in before you can comment on or make changes to this bug.
Description opensuse.lietuviu.kalba 2013-03-09 12:27:48 UTC
Created attachment 76217 [details]
Diagram to be copied

Problem description: 
I created a diagram (see attached file). Then I copy it, paste in new Calc document – here diagram in y axis became as categories, and categories became as y axis. If I paste to Write – diagram is not distorted.

Steps to reproduce:
1. Open atached document
2. copy diagram
3. paste diagram in new Calc document

Current behavior:
Categories in legend moved to y axis;
and y axis items moved to legend categories.

Expected behavior:
The same diagram is pasted
              
Operating System: openSUSE
Version: 4.0.1.2 release
Comment 1 opensuse.lietuviu.kalba 2013-03-09 12:30:20 UTC
Created attachment 76218 [details]
Distorted diagram
Comment 2 opensuse.lietuviu.kalba 2013-03-09 12:30:57 UTC
Created attachment 76219 [details]
Good diagram in Writer
Comment 3 opensuse.lietuviu.kalba 2013-03-09 12:36:50 UTC
Created attachment 76220 [details]
Image of good
Comment 4 opensuse.lietuviu.kalba 2013-03-09 12:37:24 UTC
Created attachment 76221 [details]
Image of bad diagram
Comment 5 Szuhánszky Tamás 2013-04-11 10:52:39 UTC
Hi!

I could reproduce this behavior, under Windows 7, thanks for reporting.
Comment 6 Joel Madero 2013-04-15 02:24:16 UTC
I am almost positive this is a dupe but not sure where so...

Thank you for reporting this issue! I have been able to confirm the issue on:
Version: 4.1.0.0.alpha0+Build ID: 6e3e6ef7257e93743a72719581ef6fe0016e58e
Date:   Thu Apr 11 15:24:38 2013 +0200 
Platform: Bodhi Linux 2.2 x64

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
As I've been able to confirm this problem I am marking as:

New (confirmed)
Normal - inability to do professional work
High - regression + very serious problem if one cannot copy/paste a chart correctly

Keywords - regression (works fine in 3.6.5.2)

Whiteboard Status - bibisectrequest

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link:
https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa

There are also other ways to get involved including with marketing, UX, documentation, and of course developing -  http://www.libreoffice.org/get-help/mailing-lists/. 

Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Comment 7 Aurimas Fišeras 2013-04-20 08:32:05 UTC
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

# bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# 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 8 Joel Madero 2013-04-20 15:19:48 UTC
Hey Aurimas Fišeras, 

Seems like the final step of bibisect was missed. You mind doing it again and at the end we need also "git bisect log" and the output pasted.

Thanks!
Comment 9 Aurimas Fišeras 2013-04-20 15:34:55 UTC
(In reply to comment #8)
> Seems like the final step of bibisect was missed. You mind doing it again
> and at the end we need also "git bisect log" and the output pasted.
> 
> Thanks!

Hi,
9a5620ca6473969359f262802c76daf35cbcbb5d is the first bad commit (source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc)

Everything else is a "git bisect log".
Comment 10 Markus Mohrhard 2013-05-27 23:21:45 UTC
Ok, this is again a fallout of the AOO merge.
Comment 11 Markus Mohrhard 2013-06-09 21:20:28 UTC
And looks like an error with the import code for the internal data provider. I'll need to debug it a bit more.

With the new chart export in 4.1 I can confirm that the export works correctly and that it is a pure import problem and if we use the calc data provider there is no bug but the internal data provider misses some data.
Comment 12 Björn Michaelsen 2013-06-27 10:15:38 UTC
As per Comment 10, this is "fallout from the AOO merge" and thus not a minor release regression. Setting version back to at least 4.0.0.3 release.
Comment 13 Commit Notification 2013-06-30 02:11:51 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

transpose "data in rows" ranges for internal data provider, fdo#62057



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 14 Markus Mohrhard 2013-06-30 02:14:00 UTC
This bug drove me nuts and I only have an ugly hack to fix it.

The problem as well with the other copy&paste regressions in 4.0 is that some low level changes changed the order of calls during import.
Comment 15 Markus Mohrhard 2013-07-02 02:10:53 UTC
Pending review for 4-1.
Comment 16 Commit Notification 2013-07-02 07:57:17 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

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

transpose "data in rows" ranges for internal data provider, fdo#62057


It will be available in LibreOffice 4.1.

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 17 David Tardon 2013-09-16 07:33:13 UTC
*** Bug 66455 has been marked as a duplicate of this bug. ***
Comment 18 Commit Notification 2013-11-02 18:57:24 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

Revert "transpose "data in rows" ranges for internal data provider, fdo#62057"



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 19 ulkitz 2014-04-28 12:22:08 UTC
For me this works fine in current master.
Comment 20 Xisco Faulí 2014-07-30 15:32:29 UTC
Can't reproduce it with Version: 4.2.4.2 nor with Version: 4.4.0.0.alpha0+
Build ID: ca97c608128a24d338ccbdd2a5572eb79c567aa5 under ubuntu 14.04 LTS. I close it as WORKFORME