all works well when editing the report but when running it, parameter <label in first column> is not use. X axis is wrong way rebuilt . It works only when running the report during his creation. at the time of the next modifications of the report, you have to uncheck "label in first column". Direct opening of the report from database never works. Steps to reproduce: Create a table and a report containing a diagram in ReportHeader with the following datas Datas Table : Name "Table1" Fied "Date1" type date field "Value1" type Integer Content Date1 Value1 25/01/13 10 15/02/13 20 18/03/13 25 Report : Name "Report1" Data type : Table Content : Table1 Diagram in Report Header Diagram: Data type : Table Content : Table1 Diagram Type : XY (dispersion) (in french) Data range : all, Label in first column Uncheck X Axis : Scale :"Minimum" = 02/01/2013, "main interval" = 30,416 Number : "Category" = Date, Format = "JJ/MM/AAA" Current behavior: parameter "label in first column" : ineffective Expected behavior: parameter "label in first column" : effective
X axis parameters are in french langage please
Please don't set a bug to "New", if there isn't anybody else who has reproduced the bug. Please add an example-database, so I could test it.
(In reply to comment #2) Bug confirmed see : http://nabble.documentfoundation.org/Base-Rapports-Diagramme-parametre-non-pris-en-compte-td4072002.html > Please don't set a bug to "New", if there isn't anybody else who has > reproduced the bug. > Please add an example-database, so I could test it.
Created attachment 84808 [details] Database to reproduce the problem Database to reproduce the problem
Created attachment 84812 [details] Shows the difference in charts from LO 4.1.0.3 and 4.1.1.1 - x-axis I have checked it with the data and tried to create it new. It works up to LO 4.1.0.3. First Version with this bug is LO 4.1.1.1
@chrislibreoffice Are you shure this behavior appears first in LO 4.1.0.4? I have tested this version also. There it works with Linux 64bit rpm. So I think it could have something to do with the fix of https://bugs.freedesktop.org/show_bug.cgi?id=67109. This fix first appears in LO 4.1.1.
Bug reproduce on Version 4.0.5.2 (Build ID: 5464147a081647a250913f19c0715bca595af2f) Processor AMD Athlon(tm)64 X2 Dual 5000+ Seven 64 bits the database to reproduce the problem has been created vith this version. (In reply to comment #6) > @chrislibreoffice > Are you shure this behavior appears first in LO 4.1.0.4? I have tested this > version also. There it works with Linux 64bit rpm. So I think it could have > something to do with the fix of > https://bugs.freedesktop.org/show_bug.cgi?id=67109. This fix first appears > in LO 4.1.1.
(In reply to comment #6) Sorry the concerned versions are 4.0.4, 4.0.5 and 4.1.0 > @chrislibreoffice > Are you shure this behavior appears first in LO 4.1.0.4? I have tested this > version also. There it works with Linux 64bit rpm. So I think it could have > something to do with the fix of > https://bugs.freedesktop.org/show_bug.cgi?id=67109. This fix first appears > in LO 4.1.1.
(In reply to comment #8) Bug reproduce on Version: 4.1.1.2 Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 > (In reply to comment #6) > Sorry the concerned versions are 4.0.4, 4.0.5 and 4.1.0 > > > > @chrislibreoffice > > Are you shure this behavior appears first in LO 4.1.0.4? I have tested this > > version also. There it works with Linux 64bit rpm. So I think it could have > > something to do with the fix of > > https://bugs.freedesktop.org/show_bug.cgi?id=67109. This fix first appears > > in LO 4.1.1.
Created attachment 84824 [details] Current behavior screenshot current behavior
(In reply to comment #6) Bug reproduce on Version : Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 > @chrislibreoffice Are you shure this behavior appears first in LO 4.1.0.4? I > have tested this version also. There it works with Linux 64bit rpm. So I > think it could have something to do with the fix of > https://bugs.freedesktop.org/show_bug.cgi?id=67109. This fix first appears > in LO 4.1.1.
Created attachment 84825 [details] Expected Behavior screenshot expected behavior
OK, what I found is another bug. Forget comment4 and 6. I see the right behavior in the preview, when I will edit the report. Then I doubble-click on the chart. The charts show values without connection to the first column. I could change the "Data Ranges" and set "First column as label" off. Now the chart shows the right behavior. Saved the report. Start the report, had a look: the information has been gone. Again opening the report for editing and see: "Data Range" is set to "First column as label". Seems this property hasn't been saved. All this you could only notice, when you create x/y-charts. Its the same wrong behavior in all versions of LO - have tested LO 3.3.4 with the same result.
Confirming also on LO 4.0.5 OSX 10.8.4 Alex
Why is this labelled as a regression ? In which earlier version of LO did it work ?
According to comment 13, the earliest version in which this bug is present is 3.3.4 - resetting version accordingly and removing regression status. Alex
Have tested a little bit more. 1. I could not start a report with x/y-chart in reportheader in LO 3.0.0 beta1 and beta2. So the first version I could test is LO 3.0.0 beta3. Same bug there, seems to be a very old bug, existing since OOo. 2. There are many bugs working together. 2.1 The first is, that every x-axis is per default set to an interval "1", starting with "1" - seems to count the rows only. All versions up to 4.0.5.2 | 4.1.1.1 - beginning with this versions it works right in a special constellation. 2.2 The second is, that you could switch "First column as label" in the Data-Range to "off", but this isn't been saved. Next opening it is always switched again to "on". For databases I would prefer, that this is set to "off" by default - the labels are the names of the field. 2.3 The third is, that per default no «time» and no «date» is recognized by the chart-assistant. Only values like «integer» or «decimal» would work. All versions up to 4.0.5.2 | 4.1.1.1. Beginning with this versions the chart with «integer» and «decimal» is shown in the right way. Charts with «time» and «date» don't show a line at all. I will add an attachment to show the difference.
Created attachment 84877 [details] Different filed-types show different bugs in charts of a report. Try the report with LO 4.1.0.4 or any earlier version, which could open reports with charts. I have tested a version 3.3.4. Then start the same report with LO 4.1.1.1 or newer, also with LO 4.0.5.2. Both show the same: no line in the date-and-time- chart and a right integer-decimal-chart.
(In reply to comment #17) (In reply to comment #18) *please* do not mix different bugs in the same bugzilla entry.
(In reply to comment #19) > (In reply to comment #17) > (In reply to comment #18) > > *please* do not mix different bugs in the same bugzilla entry. It a little bit tricky to mix not at this point: When I have a look at the types of the field this bug has gone for integer- and decimal-fields in LO 4.1.1.1 and LO 4.0.5.2. Label in first column of diagram works in reportbuilder with this fieldtypes. This bug has changed for date- and time-fields with LO 4.1.1.1 and LO 4.0.5.2. Label in first column of diagram don't works in reportbuilder in a different way since this versions. Should I open a new bug for this (actual) behavior of LO?
(In reply to comment #20) >> *please* do not mix different bugs in the same bugzilla entry. > It a little bit tricky to mix not at this point: > When I have a look at the types of the field this bug has gone for integer- > and decimal-fields in LO 4.1.1.1 and LO 4.0.5.2. Label in first column of > diagram works in reportbuilder with this fieldtypes. That is *not* what this bug is (claims to be?) about. The issue is that UNsetting "label in first column" does not work. And never worked. You seem to describe the bug that date values stopped working in 4.1.1 and 4.0.5.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a0b2d9371b47689d34fc238c73ebc1126cba5b1 fdo#68663 open chart-in-report: actually test for categories presence 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b090cbdf82e0827234caf5969124f6631311ef35 fdo#68663 don't blindly force categories when there are none 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.
I forked the date-related issue in bug 68781. My "fix" for this bug may have broken backwards compatibility with old files, so I'm going to consult with other developers before backporting to 4.1/4.0.
(In reply to comment #9 of bug 72727) > (In reply to comment #8) >> (In reply to comment #7) >>> I'm not happy with the commit. It clearly breaks copy&paste and categories >>> are not necessarily written out. I would vote to revert the patch and look >>> for a proper fix without breaking chart2 in all other applications. >> Who understands the principles of the charts code? When should categories be >> present and when not, and whose responsibility is it to add them / how can >> an application signal to the chart code it does not want categories? > I think currently I'm the one knowing most about the chart code. > I would need to explore why base is behaving different than calc, writer, > impress but an initial look at the file shows that the data table has > a slightly different form. Markus, since we reintroduced this bug to fix bug 72727, do you have some time to help me fix this bug without retintroducing bug 72727? Thanks in advance.
Surely, this should be re-opened as the fix was reverted, and the symptoms are once again present ?
*** Bug 100380 has been marked as a duplicate of this bug. ***
*** Bug 100381 has been marked as a duplicate of this bug. ***
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue