Created attachment 103928 [details]
Configuring group header
LibreOffice 126.96.36.199 and 188.8.131.52:
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 184.108.40.206 and 220.127.116.11
- Output workaround_Loo425.odt highlighting a workaround with LibeOffice 18.104.22.168 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 22.214.171.124 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: 126.96.36.199 release
Created attachment 103929 [details]
test_entete.odb the Data base
Created attachment 103930 [details]
origine_Aoo410.odt the expected result
Created attachment 103931 [details]
origine_Loo425.odt Wrong result from LOO 4.2.5
Created attachment 103932 [details]
workaround_Loo425.odt when header is not repeated
(In reply to comment #0)
instead of :
"State [b] origine_Aoo410.odt [/ b]"
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 188.8.131.52 (OpenSUSE 12.3, 64bit rpm Linux), doesn't work first with LO 184.108.40.206alpha0. So it's a regression.
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:
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
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: email@example.com
Author: Michael Stahl <firstname.lastname@example.org>
Date: Tue Jul 31 17:25:44 2012 +0200
_SetGetExpFlds: this looks simpler with upper_bound
Adding self to CC if not already on
*** Bug 91805 has been marked as a duplicate of this bug. ***
ubuntu+cinnamon 64bit, LO 220.127.116.11, 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.
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.
Created attachment 117016 [details]
Repeated header works, if it's not the first header
Not yet fixed in
Version: 18.104.22.168 (x64)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale : fr-FR (fr_FR)
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
The result should have been
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.
Migrating Whiteboard tags to Keywords: (bibisected)
Adding Cc: to Michael Stahl
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:
Author: Lionel Elie Mamane <email@example.com>
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
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 22.214.171.124, the fields are properly displayed, so i'll try to track
down bug #3 now...
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?
> 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 <firstname.lastname@example.org>
> 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/>
many pages of detail, e.g. 5 pages
<the next page, should have page style 2/>
while another document could be:
<now page style 1/>
<the next page, should have page style 2/>
<the next page, should have page style 3/>
<the next page, should have page style 4/>
<the next page, should have page style 5/>
... etc but no page break happens, so they page styles are never used...
<the next page, should have page style 12/>
.... 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 ...?
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.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Bug still exits in LO 126.96.36.199, OpenSUSE 15, 64bit rpm Linux
The issue is still there with:
Version: 188.8.131.52 (x64)
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
Threads CPU : 8; OS : Windows 10.0; UI Render : par défaut;
Locale : fr-FR (fr_FR); Calc: group threaded
*** Bug 123469 has been marked as a duplicate of this bug. ***