Bug 82097 - REPORTBUILDER: Group Header keeps the values of the first group
Summary: REPORTBUILDER: Group Header keeps the values of the first group
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, bisected, regression
: 91805 123469 (view as bug list)
Depends on: 103025
Blocks: Database-Reports-Builder
  Show dependency treegraph
 
Reported: 2014-08-03 16:53 UTC by ClDc
Modified: 2019-02-15 06:26 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Configuring group header (158.27 KB, image/jpeg)
2014-08-03 16:53 UTC, ClDc
Details
test_entete.odb the Data base (13.53 KB, application/vnd.sun.xml.base)
2014-08-03 16:55 UTC, ClDc
Details
origine_Aoo410.odt the expected result (13.06 KB, application/vnd.oasis.opendocument.text)
2014-08-03 16:57 UTC, ClDc
Details
origine_Loo425.odt Wrong result from LOO 4.2.5 (15.53 KB, application/vnd.oasis.opendocument.text)
2014-08-03 17:00 UTC, ClDc
Details
workaround_Loo425.odt when header is not repeated (15.62 KB, application/vnd.oasis.opendocument.text)
2014-08-03 17:01 UTC, ClDc
Details
Repeated header works, if it's not the first header (13.59 KB, application/vnd.oasis.opendocument.database)
2015-07-03 10:34 UTC, Robert Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ClDc 2014-08-03 16:53:10 UTC
Created attachment 103928 [details]
Configuring group header

Hi,

LibreOffice 4.2.5.2 and 4.3.0.4: 
In some cases, the group header is not updated in a report defined with ReportBuilder. 
The values ​​shown are those in the first group. 

The attached files : 

- test_entete.odb  database which contains an "origin" report showing the problem and a "workaround" report, copy of the previous showing the parameter causing the problem. 
- State [b] origine_Aoo410.odt [/ b] showing the expected generated successfully with Apache OpenOffice 4.1.0 from the report "original" result 
- Output origine_Loo425.odt showing the wrong result generated by LibreOffice 4.2.5.2 and 4.3.0.4 
- Output workaround_Loo425.odt  highlighting a workaround with LibeOffice 4.2.5.2 but not 100% satisfactory 

- Data Base test_entete.odb contains the table "liste", with 2 columns "document" and "detail" 

The purpose of the report "origin" is to print documents with a new page for each document, the header will contain the document number. If a document is printed on multiple pages each of them will contain the header of the document, so it involves the settings you can see in attached file  maj.jpg .

- As explained above, this report will generate origine_Loo425.odt, we see that the header for all the documents contains: 2014-01 
- The expected result is origine_Aoo410.odt (ApacheOpenOffice) header takes the values​​: 2014-01, 2014-02, 2014-03 
   documents 2014-01 and 2014-03 held on 2 pages, their header is repeated on every page .
- The "workaround" report is a copy of "origin" with the exception of the parameter "Repeat Section" becomes "no" 
workaround_Loo425.odt is the result: the header takes the values​​: 2014-01, 2014-02, 2014-03, the documents 2014-01 , 2014-03 held on 2 pages, but the header is not repeated on each page, it is not suitable. 
It worked for years in the inherited OOO versions until the 4.1.5.3 version of LibreOffice versions. 
The only solution for now is to use ApacheOpenOffice 4.0.1 and 4.1.0 versions giving the exected result. 

Thanks for your help
Operating System: Windows 7
Version: 4.2.5.2 release
Comment 1 ClDc 2014-08-03 16:55:55 UTC
Created attachment 103929 [details]
test_entete.odb the Data base
Comment 2 ClDc 2014-08-03 16:57:33 UTC
Created attachment 103930 [details]
origine_Aoo410.odt  the expected result
Comment 3 ClDc 2014-08-03 17:00:05 UTC
Created attachment 103931 [details]
origine_Loo425.odt  Wrong result  from LOO 4.2.5
Comment 4 ClDc 2014-08-03 17:01:31 UTC
Created attachment 103932 [details]
workaround_Loo425.odt when header is not repeated
Comment 5 ClDc 2014-08-03 17:09:06 UTC
(In reply to comment #0)

instead of :

"State [b] origine_Aoo410.odt [/ b]"

read:

output origine_Aoo410.odt
Comment 6 Robert Großkopf 2014-08-12 05:36:25 UTC
You are right. The value for document in the group-header doesn't change for the next group.
Have tested it with different versions of LO. Works in LO 4.1.6.2 (OpenSUSE 12.3, 64bit rpm Linux), doesn't work first with LO 4.2.0.0alpha0. So it's a regression.
Comment 7 Matthew Francis 2014-12-21 16:25:45 UTC
Bibisect results from 43all:
Two issues in reproducing this. Firstly, the "expected result" document only shows the expected result when opened in AOO. Secondly, in a lot of versions around the commit, Base corrupts the database when generating the report.


There are only 'skip'ped commits left to test.
The first bad commit could be any of:
0e54cced22ee8d216a783202cf26384317db0959
2e349599ef946cf01cfe40929509254c596fdca3
7d3d1a6f00503d8d402f5069e746ec5eb492a096
7d63b17e3d3fe488e34de32ffa042559dbad3cfd
5bac99c03c8d9c687c11c53285a65e79af6c8ef5
We cannot bisect more!
asbel@ramiel:~/Development/LibreOffice/bibisect-43all$ git bisect log
# bad: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
# good: [782be4193770a332476f99538efa5967d79af5c3] source-hash-8757c9c462ba690de60602404ef2e9e99702f0b4
git bisect start 'last41onmaster' '782be4193770a332476f99538efa5967d79af5c3'
# bad: [ca34486a7bc19acb3ddfa7b4fc27ce8bae42c66a] source-hash-bec62421a45da89d2812bdff30fbbab73291cf91
git bisect bad ca34486a7bc19acb3ddfa7b4fc27ce8bae42c66a
# skip: [ad874a5319e9f68e6b3a974e44de838b8a0a82e1] source-hash-4b4ca8030285bd66526ff5bb2b6ea5a75a6c6bc7
git bisect skip ad874a5319e9f68e6b3a974e44de838b8a0a82e1
# skip: [7be7cf83087144563a18000acdae82c8fd6f4872] source-hash-d59024b652ccfaf7247da113ec36788fe260de74
git bisect skip 7be7cf83087144563a18000acdae82c8fd6f4872
# skip: [56e0b2e447c2ff52af50c3469dc5e565d86c14df] source-hash-fcda0878e99d5792e150705f63f3ba25b5d8d14c
git bisect skip 56e0b2e447c2ff52af50c3469dc5e565d86c14df
# bad: [37d651b903e8d0d704f746e27165e92c3333750b] source-hash-9351d0e4181924c3f72be24081fc7af027aa41f7
git bisect bad 37d651b903e8d0d704f746e27165e92c3333750b
# skip: [69497016bae6f296c763f76670153dbe6a2f265d] source-hash-bed3049c4c04a202ff288189d225ca6e5941d69b
git bisect skip 69497016bae6f296c763f76670153dbe6a2f265d
# skip: [638cb54cb50a2b1269009db83f70792cf5076abc] source-hash-877c96a601e6e50d0c7a8f704d57baec22f089c5
git bisect skip 638cb54cb50a2b1269009db83f70792cf5076abc
# skip: [cefa3613b0ac72135d68a3b4fa1ff5dcd47ca6e0] source-hash-fdda178d888127c4b4dafd4b53800989929e9b6b
git bisect skip cefa3613b0ac72135d68a3b4fa1ff5dcd47ca6e0
# good: [e4c742a9e244bd7ebeabc50c90182df28ac3daaf] source-hash-c52ba433491afbca70aa1977a624c795bdd5b9ef
git bisect good e4c742a9e244bd7ebeabc50c90182df28ac3daaf
# good: [9324d2db2ab5b11184d1280c914fb7d49e57ab55] source-hash-51065497ea83e90764860784dc6e193faaf0d673
git bisect good 9324d2db2ab5b11184d1280c914fb7d49e57ab55
# bad: [241d451e09694446622f9767fb76db50481c9e32] source-hash-c3aa1cefdc6521d34a2a32c20bae1593e1edb5ba
git bisect bad 241d451e09694446622f9767fb76db50481c9e32
# bad: [5bac99c03c8d9c687c11c53285a65e79af6c8ef5] source-hash-20d4cd5e08c1400fcc5ae5eb45861f429b914969
git bisect bad 5bac99c03c8d9c687c11c53285a65e79af6c8ef5
# good: [18518588d8414f446ece5591944766f5082ebef5] source-hash-82c25249e624cb54ca6d3293d1c3d0d8ebc208e0
git bisect good 18518588d8414f446ece5591944766f5082ebef5
# skip: [0e54cced22ee8d216a783202cf26384317db0959] source-hash-2815396a1813cb3956c5aba066de49a7f34bc657
git bisect skip 0e54cced22ee8d216a783202cf26384317db0959
# skip: [7d63b17e3d3fe488e34de32ffa042559dbad3cfd] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435
git bisect skip 7d63b17e3d3fe488e34de32ffa042559dbad3cfd
# skip: [2e349599ef946cf01cfe40929509254c596fdca3] source-hash-cf2bdd65945d2a02af44db535cf1964d4d09ae20
git bisect skip 2e349599ef946cf01cfe40929509254c596fdca3
# skip: [7d3d1a6f00503d8d402f5069e746ec5eb492a096] source-hash-f9a453fb01908e16032abdbf1f895666e1d260a6
git bisect skip 7d3d1a6f00503d8d402f5069e746ec5eb492a096
# good: [a035fba5e34dc12e2b1796af6ec46f04647a3576] source-hash-df9b0d2e930eb1f60e429301e5386f742a1676ff
git bisect good a035fba5e34dc12e2b1796af6ec46f04647a3576
# only skipped commits left to test
# possible first bad commit: [5bac99c03c8d9c687c11c53285a65e79af6c8ef5] source-hash-20d4cd5e08c1400fcc5ae5eb45861f429b914969
# possible first bad commit: [7d3d1a6f00503d8d402f5069e746ec5eb492a096] source-hash-f9a453fb01908e16032abdbf1f895666e1d260a6
# possible first bad commit: [2e349599ef946cf01cfe40929509254c596fdca3] source-hash-cf2bdd65945d2a02af44db535cf1964d4d09ae20
# possible first bad commit: [0e54cced22ee8d216a783202cf26384317db0959] source-hash-2815396a1813cb3956c5aba066de49a7f34bc657
# possible first bad commit: [7d63b17e3d3fe488e34de32ffa042559dbad3cfd] source-hash-83837d6514217c82ebe8d56dddf89fa34f4b5435
Comment 8 Matthew Francis 2014-12-22 13:20:36 UTC
The below appears to be the commit that introduced the bug

(Note regarding building the original bug:
50cf7caee5bc6d8e066580d13c72b40926fcb69a introduced another bug which prevents reproduction of this bug. Manually apply 6868efe203cffda0ab60db2abc4637433e6caf90 in order to be able to test in the region of the bug)

(Note 2: The methods patched by the below now reside in sw/source/core/doc/DocumentFieldsManager.cxx)


Adding Cc: mstahl@redhat.com


commit 2815396a1813cb3956c5aba066de49a7f34bc657
Author: Michael Stahl <mstahl@redhat.com>
Date:   Tue Jul 31 17:25:44 2012 +0200

    _SetGetExpFlds: this looks simpler with upper_bound
    
    Change-Id: I37dd291aaa229493141fbb8b426488e8e4427185
Comment 9 Alex Thurgood 2015-01-03 17:39:45 UTC Comment hidden (no-value)
Comment 10 Robert Großkopf 2015-06-02 12:49:13 UTC
*** Bug 91805 has been marked as a duplicate of this bug. ***
Comment 11 Ηλίας Ηλιάδης 2015-07-03 09:13:47 UTC
ubuntu+cinnamon 64bit, LO 4.2.8.2,  420m0(Build:2)
I do not know if this the same as Bug 91805 so I report here.
Trying to repeat the header of the group (it contains the name of the group as well as the column headers for the details that will be present in the report) the result was the repetition of the header of the first group even when group changed.
I am confused. Is there another way to create such a report and the purpose of repeating header is actually to repeat the header independedly of the group change (aka just used to repeat some column headers)?
Or this is a bug and the purpose of repeating the header is indeed to be repeated and change with each group change?
My report includes also a footer for the group.
Counters added to detail section, change OK with every group change.
Comment 12 Robert Großkopf 2015-07-03 10:32:39 UTC
Here is a workaround for this bug:
Add the same group as group header.
Set this group as the first group.
Set General → Visible → No

Now the original first group is the second group - and will be repeated.
Comment 13 Robert Großkopf 2015-07-03 10:34:02 UTC
Created attachment 117016 [details]
Repeated header works, if it's not the first header
Comment 14 ClDc 2015-09-04 10:08:14 UTC
Not yet fixed in
Version: 5.0.1.2 (x64)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale : fr-FR (fr_FR)
Windows 10


Thanks to Robert his workaround worked for the 2 reports I tested.

But for one of the reports I noticed a strange behavior.

I try to explain:

1) the 2 first documents on 18, had the same header
2015-01 

The result should have been
2015-01
2015-02


2) I edited the odt file still opened and updated the header of the second document as "2015-02", unfortunately it updateted also the first header

3) I saved the odt file on a working file on disk, in order to disconnct it from database, I opened it to update and I noticed that the both header were correct without any modification done to the saved odt file. Then I generated the PDF from the save odt file and all was correct.

When I use report builder I never save the generated odt file, I generate a PDF and delelete the odt file window

I am not able to find why it worked for one document and not the other one.
Comment 15 Robinson Tryon (qubit) 2015-12-13 11:16:20 UTC Comment hidden (obsolete)
Comment 16 Xisco Faulí 2016-09-26 15:21:16 UTC
Adding Cc: to Michael Stahl
Comment 17 Michael Stahl (CIB) 2016-10-05 11:56:34 UTC
oops, somehow i wasn't aware of this issue...

... there are 2 bugs here, the one from the commit in comment #8 was
fixed (bug 60886) but on current master i don't even see any fields in
Writer because in /tmp/lu*.tmp/origine.odt styles.xml the
report-builder generates a plain text "2014-01" string instead of
a field like 4.1.6 did:

<text:variable-get text:name="auto_group_1_1" office:value-type="string">2014-03</text:variable-get>

this problem was also introduced between 4.1.6 and 4.2.0...

i'm pretty sure this is responsible:

commit fc92c1abebcfe9b18649d35b76bf22e001e332da
Author:     Lionel Elie Mamane <lionel@mamane.lu>
AuthorDate: Mon Aug 12 18:41:44 2013 +0200

    fdo#67930 don't use variables for formattedtext in header/footer
    
    I don't know why it was going through variables.
    Instead, put the value where it is supposed to,
    like for formattedtext in detail section.
    Try it, and if something breaks, we can revert.
    
    This also works around fdo#67930


this commit was reverted in commit d6ce95ae2288859fe74d601f1bdaf616ab1ee7f0
but then again un-revert in commit 08715e24c13d21767544725292d8dbf1c2381479

and if i revert the latter on master i get the "variable-get" fields,
but writer doesn't evaluate them like 4.1.6 did and the result is
always 2014-01, with or without 2815396a1813cb3956c5aba066de49a7f34bc657
reverted.

now, looking at this bug: a hard-coded string value in a header obviously
cannot change between different pages; either report-builder actually needs
to put those variables back in, or report-builder needs to generate
multiple page styles with different hard-coded headers.

if i open the document written by report-builder master with reverts
in 4.2.8.2, the fields are properly displayed, so i'll try to track
down bug #3 now...
Comment 18 Michael Stahl (CIB) 2016-10-05 21:57:07 UTC
the 3rd problem is a regression in 5.0 tracked in bug 103025 now fixed.

remains to decide whether to revert the variable-get removal or
generate multiple page styles - Lionel, opinions?
Comment 19 Xisco Faulí 2016-11-22 13:09:46 UTC
lowering severity
Comment 20 Lionel Elie Mamane 2017-08-09 17:04:16 UTC
> on current master i don't even see any fields in
> Writer because in /tmp/lu*.tmp/origine.odt styles.xml the
> report-builder generates a plain text "2014-01" string instead of
> a field like 4.1.6 did:

> i'm pretty sure this is responsible:

> commit fc92c1abebcfe9b18649d35b76bf22e001e332da
> Author:     Lionel Elie Mamane <lionel@mamane.lu>
> AuthorDate: Mon Aug 12 18:41:44 2013 +0200
 
>     fdo#67930 don't use variables for formattedtext in header/footer
     
>     I don't know why it was going through variables.
>     Instead, put the value where it is supposed to,
>     like for formattedtext in detail section.
>     Try it, and if something breaks, we can revert.
    
>     This also works around fdo#67930

> this commit was reverted in commit d6ce95ae2288859fe74d601f1bdaf616ab1ee7f0
> but then again un-revert in commit 08715e24c13d21767544725292d8dbf1c2381479

> and if i revert the latter on master i get the "variable-get" fields,
> but writer doesn't evaluate them like 4.1.6 did and the result is
> always 2014-01, (...)

> now, looking at this bug: a hard-coded string value in a header obviously
> cannot change between different pages; either report-builder actually needs
> to put those variables back in, or report-builder needs to generate
> multiple page styles with different hard-coded headers.

When I yanked the variables out, I didn't understand / see that these could show up in a page header afterwards. All I was seeing is a variable that was set, and then immediately used once, in the body of the document.

Now, we have an understanding of at least one "real role" these variables had:
 each new group opening (re)sets the variables
 if the group header is supposed to be repeated, it is placed in the page header
 the page header uses the variables set

You now propose another way to achieve the same, namely Report Builder emits constant values, but puts them in uniquely numbered page styles. I rather like this idea, because the variables handling has proven to be a mess in the past:

 * Writer bugs
 * The OpenDocument spec specifies something different
   than what Report Builder expects, so Writer special cases (!!!)
   the constructs used by Report Builder!
 * Just plain fragility

But, I expect that for this to make sense, we need, each time a new (repeated) group starts, to:

 * generate a new unique page style (theoretically no problem)
 * emit a tag that says "the *next* page will have this style"
   (_not_ the *current* page!)
 * that tag should _NOT_ force a page break

The point about not being a page break is absolutely crucial; Report Builder has no clue where a page break will be, the page breaking _must_ be done entirely by Writer.

Does such a tag exist? I didn't find out to set that in the Writer UI. Setting "next style" shows some promise, but I'm afraid that is not it. I expect "next style" must be set as a setting of the whole page style, and means that only one page will have the current style. While what we need is:


<now page style 1/>
detail
detail
detail
...
...
many pages of detail, e.g. 5 pages
....
detail
<the next page, should have page style 2/>
detail
detail
detail
detail
...



while another document could be:

<now page style 1/>
detail
detail
<the next page, should have page style 2/>
detail
detail
<the next page, should have page style 3/>
detail
detail
<the next page, should have page style 4/>
detail
detail
<the next page, should have page style 5/>
detail
detail
... etc but no page break happens, so they page styles are never used...
....
....
<the next page, should have page style 12/>
detail
.... here the Writer layout engine decides a pagebreak is in order
... a new page starts, and it has page style 12

If such a tag doesn't exist, could we possibly get one? E.g. as a LibreOffice extension, or something to be added to some future version of the standard, or ...?
Comment 21 Michael Stahl (CIB) 2017-08-09 20:23:45 UTC
those are some good questions.

the page styles could be set up so that page-style-N has its style:next-style-name attribute set to page-style-N+1.

but the problem with this idea is that the report builder would still need to know how many pages there will be ("5 pages of detail"), which is not really possible if it doesn't do its own page layout that is identical to Writer.

so it looks like the variables are the better approach after all.
Comment 22 QA Administrators 2018-08-10 02:38:38 UTC Comment hidden (obsolete)
Comment 23 Robert Großkopf 2018-08-10 05:56:49 UTC
Bug still exits in LO 6.1.0.3, OpenSUSE 15, 64bit rpm Linux
Comment 24 ClDc 2018-08-13 10:51:01 UTC
Hi,

The issue is still there with:

Version: 6.1.0.3 (x64)
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
Threads CPU : 8; OS : Windows 10.0; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: group threaded

Thanks
Comment 25 Alex Thurgood 2019-02-15 06:26:46 UTC
*** Bug 123469 has been marked as a duplicate of this bug. ***