Bug 134699 - FILEOPEN: ODT: REPORT: Section "Detail" won't be shown on first page, if content has more than one page
Summary: FILEOPEN: ODT: REPORT: Section "Detail" won't be shown on first page, if cont...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-07-09 20:41 UTC by Emiliano A. González
Modified: 2020-07-17 19:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Report 1 (198.81 KB, image/png)
2020-07-09 20:42 UTC, Emiliano A. González
Details
Report 2 (212.39 KB, image/png)
2020-07-09 20:43 UTC, Emiliano A. González
Details
report correct (65.20 KB, application/pdf)
2020-07-09 20:44 UTC, Emiliano A. González
Details
report wrong (53.44 KB, application/pdf)
2020-07-09 20:46 UTC, Emiliano A. González
Details
report correct 7.0.0.1 (59.83 KB, application/pdf)
2020-07-09 20:46 UTC, Emiliano A. González
Details
Database (562.05 KB, application/vnd.sun.xml.base)
2020-07-09 20:47 UTC, Emiliano A. González
Details
File generated by Base. Open it to reproduce the issue (29.81 KB, application/vnd.oasis.opendocument.text)
2020-07-13 12:04 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emiliano A. González 2020-07-09 20:41:44 UTC
Description:
libreoffice 7.0.0.1
Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd
Subprocs. CPU: 8; SO: Linux 5.7; Repres. IU: predet.; VCL: kf5
Locale: es-ES (es_ES.UTF-8); Interfaz: es-ES
LibreOffice Base

Report conducted with report builder.
Report with one page without problem.
Report with two or more pages starts the detail on the next page, being blank from the header to the end of the first page.
The report contains three sections:
Group Header
Detail
Group Footer

In the previous version (6.4.5.2) it is shown correctly.

Steps to Reproduce:
1.- 
2.-
3.-

Actual Results:
-

Expected Results:
-


Reproducible: Always


User Profile Reset: No



Additional Info:
-
Comment 1 Emiliano A. González 2020-07-09 20:42:54 UTC
Created attachment 162858 [details]
Report 1
Comment 2 Emiliano A. González 2020-07-09 20:43:36 UTC
Created attachment 162859 [details]
Report 2
Comment 3 Emiliano A. González 2020-07-09 20:44:59 UTC
Created attachment 162860 [details]
report correct
Comment 4 Emiliano A. González 2020-07-09 20:46:17 UTC
Created attachment 162861 [details]
report wrong
Comment 5 Emiliano A. González 2020-07-09 20:46:56 UTC
Created attachment 162862 [details]
report correct 7.0.0.1
Comment 6 Emiliano A. González 2020-07-09 20:47:31 UTC
Created attachment 162863 [details]
Database
Comment 7 Robert Großkopf 2020-07-10 06:07:13 UTC
Couldn't confirm any buggy behavior here.
Please write down a detailed description.
I opened all forms in LO 7.0.0.1 on OpenSUSE 15.1 64bit rpm Linux. All will show the content the right way. Which of the reports shows the wrong content for you?
Comment 8 Emiliano A. González 2020-07-10 16:58:28 UTC
Report where the problem has been detected: "Movimientos_por_fecha_y_cuenta"
Attachments:
Database: Database "Bancos_7.0.0.1.odb"
Report 1: Edit report 6.4.5.2 correct Altura (Height) 0,50 cm
Report 2: Edit report 7.0.0.1 wrong Altura (Height) -0,01 cm
Report wrong: Report 7.0.0.1 detail on the next page, being blank from the header to the end of the first page.
Records exceed one page, not as in "Report correct 7.0.0.1"
Comment 9 Robert Großkopf 2020-07-10 17:29:27 UTC
(In reply to Emiliano A. González from comment #8)
> Report where the problem has been detected: "Movimientos_por_fecha_y_cuenta"

> Report wrong: Report 7.0.0.1 detail on the next page, being blank from the
> header to the end of the first page.

The database you added gives a report with date "01 febrero 2020" - only one page. Could this be the reason I can't confirm any bug there?
Comment 10 Robert Großkopf 2020-07-10 17:43:53 UTC
So, after changing the content of one table, I could reproduce the bug:
Open the attached database.
Open the report "Movimientos_por_fecha_y_cuenta"
All looks right in every LO-version. Report has 1 page.
Close the report.

Open table "Prametros".
Change "fecha_fin" to 2020-07-01 (don't know how it is formatted for the user, could be 01.07.20)
Close the table.
Open the report "Movimientos_por_fecha_y_cuenta"
Now the report will get all content for section Detail on the second and third page. The first page shows only the header.

This bug appears since LO 7.0.0.0beta2, could also appear in older LO 7 versions. It doesn't appear, for example, in LO 6.4.5.2

Tested all on OpenSUSE 15.1 64bit rpm Linux
Comment 11 Emiliano A. González 2020-07-10 18:15:30 UTC
To reproduce it graphically:
Forms: Informe
Fecha inicio: 11/11/2019 dd/MM/yyyy
Fecha final: 03/05/2020 dd/MM/yyyy
Button: "Refrescar"  Yes
Button: "Informe por fecha y cuenta"
Comment 12 Emiliano A. González 2020-07-10 18:17:30 UTC
It does not appear, for example, in LO 6.4.5.2 or earlier
Comment 13 Xisco Faulí 2020-07-13 12:03:27 UTC
This is not a base problem but a Writer problem
Comment 14 Xisco Faulí 2020-07-13 12:04:09 UTC
Created attachment 162965 [details]
File generated by Base. Open it to reproduce the issue
Comment 15 Xisco Faulí 2020-07-13 12:05:40 UTC
Regression introduced by:

commit 8a21d5053d331160e4913dc80c045a454ec84de3
Author: Justin Luth <justin.luth@collabora.com>
Date:   Mon May 4 22:21:46 2020 +0300

tdf#132642 sw layout: try2 emulate table kept-with-next not splitting

Bisected with: bibisect-linux64-7.0

Adding Cc: to Justin Luth
Comment 16 Justin L 2020-07-13 16:29:31 UTC
Comment 14's document looks the same as it looked in LO 5.1 - before my 5.2 changes which were not intended to affect ODT.

It seems like the reports are poorly designed.  Why is the table property set so that it may not split across pages? That is the ultimate problem here. I can see why the small header and footer might not want to split at all, but the detail should be allowed to split across pages.  The "keep with next paragraph" property OUGHT to help keep the whole report on a single page if possible.

So basically, the report is doing just what it is told to do. All of the detail is held in a separate table. If the table properties are changed to that the table is allowed to split across pages, it will work as desired.

There is a report setting that will mostly do this - but it is buried pretty deep. When editing the report, go to view menu - sorting and grouping.  You want "Keep together" "with first detail".  (The only thing this misses is keeping the footer table together, and keeping the detail with the footer - in the unlikely circumstance that some text is added above the report.) [The default seems to be "off", so the designer deliberately set this?]
Comment 17 Emiliano A. González 2020-07-13 17:00:38 UTC
The error is presented with version 7.0.0.1rc1.
Not with older versions. I have made the same report with both versions. 
Examples:

Attachment 162860 [details] report correct - LibreOffice 6.4.5.2
Attachment 162861 [details] report wrong   - LibreOffice 7.0.0.1

The requested data is the same in both reports.
No changes have been made to the database.
Comment 18 Justin L 2020-07-13 18:39:38 UTC
(In reply to Emiliano A. González from comment #17)
> The error is presented with version 7.0.0.1rc1., not with older versions.
It is present in older versions. Test with versions older than 5.2.

The bug actually starts in 5.2 because a table is split that is specifically set not to split. That bug was fixed in 7.0. Your reports need to have the settings adjusted to properly define the results you want to see.
Comment 19 Robert Großkopf 2020-07-13 19:26:09 UTC
Yes, seems to be a bug in the design of Report Builder. Have tested in LO 5.1.5.2 with the same problem. If you mark the table and set Table Format to Text Flow → Allow Table to split ... it will work.

But how do we solve the bug in Report Builder. I would prefer it will work right now in Writer as it does in LO 7.0.0.1. And the code of ReportBuilder should be changed to work the right way also.

I don't see any developer, who will change code in ReportBuilder. In the last 10 years there has only be added one function. Bugs appear and weren't solved ...
Comment 20 Justin L 2020-07-13 19:31:17 UTC
You missed this important part...

(In reply to Justin L from comment #16)
> There is a report setting that will mostly do this - but it is buried pretty
> deep. When editing the report, go to view menu - sorting and grouping.  You
> want "Keep together" "with first detail".


>  (The only thing this misses is keeping the footer table together
... actually it does this. The footer table is still do-not-split...
> , and keeping the detail with the footer
... which is basically irrelevant
Comment 21 Emiliano A. González 2020-07-13 21:04:53 UTC
According to comment 16. Justin L.
At the time of the creation of the report it was the only option, because I had a lot of problems with the adjustments.
Report Builder sometimes works the way you want it to.
I don't have much knowledge of English, but thanks to Deepl https://www.deepl.com/translator I have been able to get in touch with you.
Thank you all and a greeting,
Emiliano
Comment 22 Robert Großkopf 2020-07-14 06:07:43 UTC
If you are using Macros to open the report the following should work:

SUB TabSplit
DIM oReport AS OBJECT
DIM oTables AS OBJECT
DIM oTable AS OBJECT
DIM inT AS INTEGER
DIM inI AS INTEGER	
oReport = ThisDatabaseDocument.ReportDocuments.getByName("Movimientos_por_fecha_y_cuenta").open
oTables = oReport.getTextTables()
FOR inT = 0 TO oTables.count() - 1
	oTable = oTables.getByIndex(inT)
	IF Left$(oTable.name, 6) = "Detail" THEN
		oTable.Split = True
	ENDIF
	NEXT inT
END SUB

The report will be opened by a button, for example in a Base form. Tested this with the generated file of the report.

Hope someone will fix this in the ReportBuilder.
Comment 23 Justin L 2020-07-14 07:00:21 UTC
(In reply to Robert Großkopf from comment #22)
> Hope someone will fix this in the ReportBuilder.
Robert - what exactly needs fixing? Once the report is given the proper settings for this particular report as mentioned in comment 20, it works fine AFAICS.
Comment 24 Robert Großkopf 2020-07-14 07:20:15 UTC
(In reply to Justin L from comment #23)
> (In reply to Robert Großkopf from comment #22)
> > Hope someone will fix this in the ReportBuilder.
> Robert - what exactly needs fixing? Once the report is given the proper
> settings for this particular report as mentioned in comment 20, it works
> fine AFAICS.

Open the report for editing in Base.
Change all you are able to change for section Detail, specially "Keep Together" → 'No'
The report will show the same behavior as reported for this bug.
Split won't be allowed for the table in the executed report.
The button for editing the report does ... nothing.

Tested in LO 7.0.0.1 with OpenSUSE 15.1 64bit rpm Linux
Comment 25 Justin L 2020-07-14 07:23:02 UTC
(In reply to Robert Großkopf from comment #24)
> Open the report for editing in Base.
> Change all you are able to change for section Detail, specially "Keep
> Together" → 'No'
That is not what comment 20 told you to do though.
Comment 26 Robert Großkopf 2020-07-14 07:39:20 UTC
(In reply to Justin L from comment #25)
> (In reply to Robert Großkopf from comment #24)
> > Open the report for editing in Base.
> > Change all you are able to change for section Detail, specially "Keep
> > Together" → 'No'
> That is not what comment 20 told you to do though.

You are right. Haven't noticed this. Thank you for the hint. The standard of the field in "Sorting and Grouping" is "Keep together" → 'No' ...
Comment 27 Robert Großkopf 2020-07-14 07:40:07 UTC
So should we close this one as WORKSFORME?
Comment 28 Emiliano A. González 2020-07-14 08:27:24 UTC
If it should be closed. 
With the solution provided by Justin L. the problem was solved. It works perfectly.
Regarding the macro of the commentary 22 of Robert Großkopf I am going to test it. 
Thank you very much.
Comment 29 Robert Großkopf 2020-07-14 08:31:47 UTC
(In reply to Emiliano A. González from comment #28)
> If it should be closed. 
> With the solution provided by Justin L. the problem was solved. It works
> perfectly.
> Regarding the macro of the commentary 22 of Robert Großkopf I am going to
> test it. 
> Thank you very much.

So let us close this one as "WORKFORME".

The macro isn't necessary. But it shows how to get the right object in the executed report. I have just tested to set borders in the table, which is very difficult in the Report-Builder. If you are interested in this write a private mail to me ...
Comment 30 Timur 2020-07-17 19:13:59 UTC
WORKFORME is when there was a bug and unknown fix (which may be revealed by rebisect).
This looks like NOTABUG (which indicates that documentation could be improved).