Bug 68663 - ReportBuilder char: unsetting "Label in first column" has no effect
Summary: ReportBuilder char: unsetting "Label in first column" has no effect
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 100380 100381 (view as bug list)
Depends on:
Blocks: 87012
  Show dependency treegraph
 
Reported: 2013-08-28 14:05 UTC by chrislibreoffice
Modified: 2021-02-12 10:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Database to reproduce the problem (89.57 KB, application/vnd.oasis.opendocument.database)
2013-08-28 18:34 UTC, chrislibreoffice
Details
Shows the difference in charts from LO 4.1.0.3 and 4.1.1.1 - x-axis (20.35 KB, image/png)
2013-08-28 19:19 UTC, Robert Großkopf
Details
Current behavior (63.91 KB, image/pjpeg)
2013-08-29 06:32 UTC, chrislibreoffice
Details
Expected Behavior (70.37 KB, image/pjpeg)
2013-08-29 06:38 UTC, chrislibreoffice
Details
Different filed-types show different bugs in charts of a report. (38.78 KB, application/vnd.sun.xml.base)
2013-08-29 18:10 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chrislibreoffice 2013-08-28 14:05:02 UTC
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
Comment 1 chrislibreoffice 2013-08-28 14:46:08 UTC
X axis parameters are in french langage please
Comment 2 Robert Großkopf 2013-08-28 16:06:50 UTC
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.
Comment 3 chrislibreoffice 2013-08-28 18:14:28 UTC
(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.
Comment 4 chrislibreoffice 2013-08-28 18:34:43 UTC
Created attachment 84808 [details]
Database to reproduce the problem

Database to reproduce the problem
Comment 5 Robert Großkopf 2013-08-28 19:19:32 UTC
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
Comment 6 Robert Großkopf 2013-08-28 19:32:01 UTC
@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.
Comment 7 chrislibreoffice 2013-08-28 20:31:53 UTC
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.
Comment 8 chrislibreoffice 2013-08-28 21:30:07 UTC
(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.
Comment 9 chrislibreoffice 2013-08-29 04:59:28 UTC
(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.
Comment 10 chrislibreoffice 2013-08-29 06:32:35 UTC
Created attachment 84824 [details]
Current behavior

screenshot current behavior
Comment 11 chrislibreoffice 2013-08-29 06:36:17 UTC
(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.
Comment 12 chrislibreoffice 2013-08-29 06:38:01 UTC
Created attachment 84825 [details]
Expected Behavior

screenshot expected behavior
Comment 13 Robert Großkopf 2013-08-29 07:57:15 UTC
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.
Comment 14 Alex Thurgood 2013-08-29 12:22:21 UTC
Confirming also on LO 4.0.5 OSX 10.8.4


Alex
Comment 15 Alex Thurgood 2013-08-29 12:27:47 UTC
Why is this labelled as a regression ?
In which earlier version of LO did it work ?
Comment 16 Alex Thurgood 2013-08-29 12:29:25 UTC
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
Comment 17 Robert Großkopf 2013-08-29 18:04:14 UTC
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.
Comment 18 Robert Großkopf 2013-08-29 18:10:21 UTC
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.
Comment 19 Lionel Elie Mamane 2013-08-29 19:00:39 UTC
(In reply to comment #17)
(In reply to comment #18)

*please* do not mix different bugs in the same bugzilla entry.
Comment 20 Robert Großkopf 2013-08-29 19:21:40 UTC
(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?
Comment 21 Lionel Elie Mamane 2013-08-30 15:54:15 UTC
(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.
Comment 22 Commit Notification 2013-08-30 16:44:30 UTC
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.
Comment 23 Commit Notification 2013-08-30 16:44:51 UTC
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.
Comment 24 Lionel Elie Mamane 2013-08-31 07:34:06 UTC
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.
Comment 25 Lionel Elie Mamane 2014-07-23 06:26:23 UTC
(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.
Comment 26 Alex Thurgood 2016-06-16 09:14:06 UTC
Surely, this should be re-opened as the fix was reverted, and the symptoms are once again present ?
Comment 27 Alex Thurgood 2016-06-16 09:32:47 UTC
*** Bug 100380 has been marked as a duplicate of this bug. ***
Comment 28 Alex Thurgood 2016-06-16 12:51:35 UTC
*** Bug 100381 has been marked as a duplicate of this bug. ***
Comment 29 Xisco Faulí 2017-07-13 11:23:12 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue