Bug 119067 - REPORTBUILDER: Report label display string lost when saved and the actual string 'LABEL' used when the report is run next.
Summary: REPORTBUILDER: Report label display string lost when saved and the actual str...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.1.1 rc
Hardware: All All
: highest critical
Assignee: Armin Le Grand
URL:
Whiteboard: target:6.2.0 target:6.1.3
Keywords: bibisected, bisected, regression
: 119907 120089 120140 120472 120477 120672 120699 120947 121020 (view as bug list)
Depends on:
Blocks: Regressions-AW080
  Show dependency treegraph
 
Reported: 2018-08-02 16:23 UTC by Drew Jensen
Modified: 2018-10-29 15:28 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:


Attachments
odb with example reports (27.54 KB, application/vnd.oasis.opendocument.database)
2018-08-02 16:25 UTC, Drew Jensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-08-02 16:23:32 UTC
Description:
Make a quick report using report wizard and the wizard code prints the word LABEL for the column head of each field in the report.

Steps to Reproduce:
1. Open the attached ODB file 
2. Go to the Reports section
3. Select Create New Report With Wizard
4. Select either query or table in the database to base it on
5. In the dialog select both fields to be included.
6. Click on fnished.

5. On the f

Actual Results:
Report is produced with the word LABEL at the head of the two columns instead of the field name that column is displaying

Expected Results:
The labels should display the column name.


Reproducible: Always


User Profile Reset: No



Additional Info:
Found using Ubuntu 18.04 w/ Version: 6.2.0.0.alpha0+
Build ID: d0a481d09e696f6d5a2a0d40a9d5c48cfca559bf
Branch:master, Time: 2018-08-02

Also checked 6.1, the bug is not there.
Comment 1 Drew Jensen 2018-08-02 16:25:52 UTC
Created attachment 143936 [details]
odb with example reports

File contains to folders (6.1 Reports and 6.2 Reports in the Reports section, each folder with two reports, all reports created with report wizard.
Comment 2 Xisco Faulí 2018-08-02 16:37:20 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=96b338e62c422ccd23cd33b3f87a463730221514

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-07-25 14:10:08 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-07-25 19:22:09 +0200
commit 96b338e62c422ccd23cd33b3f87a463730221514 (patch)
tree 69e2dfb923a6560a7375294c7531c2977cc02322
parent ad9821c92fdf6dbd39826fb71742f10c41f2155b (diff)
tdf#118730 Correct ReportDesigner Object creation

Bisected with: bibisect-linux64-6.2

Adding Cc: to Armin Le Grand
Comment 3 Rene Engelhard 2018-09-02 10:13:49 UTC
 96b338e62c422ccd23cd33b3f87a463730221514 was backported to 6.1 with https://gerrit.libreoffice.org/#/c/58321/ and is in 6.1.1rc1 now, too.

So this bug is now also present in 6.1.1 rc1 onwards. See also https://bugs.debian.org/907710
Comment 4 Drew Jensen 2018-09-16 20:26:39 UTC
*** Bug 119907 has been marked as a duplicate of this bug. ***
Comment 5 moebius20 2018-09-20 09:01:14 UTC
I confirm this bug ; bad news because noone is handling report builder problems...

Strangely, the extra-lines bug (100477) seems to have disappeared...

wait and see
Comment 6 moebius20 2018-09-20 11:53:50 UTC
Could someone change the importance item to « critical» ?
Report builder can't be used actually in this state.

cordialement,
Comment 7 Drew Jensen 2018-09-20 12:31:16 UTC
Given that RB can not be disabled any longer it is a major bug.
Comment 8 Drew Jensen 2018-09-23 15:27:37 UTC
*** Bug 120089 has been marked as a duplicate of this bug. ***
Comment 9 Drew Jensen 2018-09-26 19:15:35 UTC
*** Bug 120140 has been marked as a duplicate of this bug. ***
Comment 10 Karsten Müller 2018-09-27 21:33:43 UTC
In the odb-file last edited with LO 6.1.0.3 it seems to be o.k.

table:style-name="ce1"><text:p><rpt:fixed-content><text:p>Lieferdatum</text:p><rpt:report-element><rpt:report-component draw:name="Beschriftungsfeld"/>

Warning: After editing and saving the report all label titles are overwritten with "Label", the original informations are lost
Comment 11 moebius20 2018-09-28 19:44:52 UTC
Bonjour,
Unfortunately, still present in LO 6.1.2 final

cordialement,
Comment 12 moebius20 2018-10-03 17:02:44 UTC
Bonsoir, 

Given that Report builder can't be used any longer, couldn't the bug be changed from major to critical ?

cordialement,
Comment 13 Alex Thurgood 2018-10-04 10:03:07 UTC
(In reply to moebius20 from comment #12)
> Bonsoir, 
> 
> Given that Report builder can't be used any longer, couldn't the bug be
> changed from major to critical ?
> 
> cordialement,

I can edit the saved Report definition via the right mouse button menu entry "Edit", to change the label names via the Properties dialog, save the report, and then re-execute the report, leading to correct display of the labels, so probably not a "critical" bug.

Version: 6.2.0.0.alpha0+
Build ID: 030181b37d2b7edd7cab20ceb7736e575186f99b
CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: threaded
Comment 14 Alex Thurgood 2018-10-04 10:04:27 UTC
(In reply to Alex Thurgood from comment #13)
> 
> I can edit the saved Report definition via the right mouse button menu entry
> "Edit", to change the label names via the Properties dialog, save the
> report, and then re-execute the report, leading to correct display of the
> labels, so probably not a "critical" bug.

Unfortunately, the saved change doesn't survive closure of the report definition, then re-execution, sigh...
Comment 15 moebius20 2018-10-04 11:15:26 UTC
(In reply to Alex Thurgood from comment #14)
> (In reply to Alex Thurgood from comment #13)
> > 
> > I can edit the saved Report definition via the right mouse button menu entry
> > "Edit", to change the label names via the Properties dialog, save the
> > report, and then re-execute the report, leading to correct display of the
> > labels, so probably not a "critical" bug.
> 
> Unfortunately, the saved change doesn't survive closure of the report
> definition, then re-execution, sigh...

Bonjour,

That's the problem and my reports contain, sometimes, a lot of labels that I can't decently rewrite every time.

So «critical» seems a good indication.

cordialement,
Comment 16 Alex Thurgood 2018-10-10 07:20:43 UTC
*** Bug 120472 has been marked as a duplicate of this bug. ***
Comment 17 Armin Le Grand 2018-10-10 09:17:26 UTC
Tried to reproduce, but get error

The connection to the data source "newFBDoc" could not be established.
Checking on the web leads to

https://bugs.documentfoundation.org/show_bug.cgi?id=97695

where it says I have to turn 'experimental features' on. Did that, still does not work.

Something special to do with Win version...?
Maybe a simpler/didfferent example...?
Comment 18 Xisco Faulí 2018-10-10 09:40:12 UTC
(In reply to Armin Le Grand (CIB) from comment #17)
> Tried to reproduce, but get error
> 
> The connection to the data source "newFBDoc" could not be established.
> Checking on the web leads to
> 
> https://bugs.documentfoundation.org/show_bug.cgi?id=97695
> 
> where it says I have to turn 'experimental features' on. Did that, still
> does not work.
> 
> Something special to do with Win version...?
> Maybe a simpler/didfferent example...?

Hi Armin,
if you're using your own build, could you please check whether you're using --disable-firebird-sdbc in autogen ?
Comment 19 Armin Le Grand 2018-10-10 09:46:37 UTC
Yes - did that - argh!
Comment 20 Xisco Faulí 2018-10-10 11:13:17 UTC
*** Bug 120477 has been marked as a duplicate of this bug. ***
Comment 21 Xisco Faulí 2018-10-10 11:50:02 UTC
Increasing severity due to the number of duplicates...
Comment 22 Armin Le Grand 2018-10-10 14:08:36 UTC
Can now reproduce.
Problem is that I was to straight in tdf#118730 in setting the default label that was set in ::EndCreate before (had to move due to having no SdrPage at that time). To make both work (interactive Field creation and Wizard) need to remember creation and set Label only to default if object was created interactively
Comment 23 Commit Notification 2018-10-10 18:44:04 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad1b8880c22a6a38b31aa2516d9d8da979c0a102

tdf#119067 DefaultLabel only for interactively created OBJs

It will be available in 6.2.0.

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 Armin Le Grand 2018-10-10 18:44:40 UTC
Should be fixed, will check locally
Comment 25 Rene Engelhard 2018-10-10 20:32:31 UTC
@alg: if it does, given the breakage also happened in 6.1.x, this needs a -6-1 backport...
Comment 26 Xisco Faulí 2018-10-11 09:38:42 UTC
Verified in

Version: 6.2.0.0.alpha0+
Build ID: 59ed21b1720db5fd0326e1b723483b288725e662
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Comment 27 moebius20 2018-10-11 10:20:06 UTC
(In reply to Rene Engelhard from comment #25)
> @alg: if it does, given the breakage also happened in 6.1.x, this needs a
> -6-1 backport...
Bonjour,

I agree with you, a backport to the 6.1 branch would be nice ; it would be annoying to wait for february to see this regression bug fixed.

cordialement,
Comment 29 Commit Notification 2018-10-11 12:22:31 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3eb084243af11b1ab5b0c940d6baa42dd63d5ad1&h=libreoffice-6-1

tdf#119067 DefaultLabel only for interactively created OBJs

It will be available in 6.1.4.

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 30 moebius20 2018-10-11 12:33:41 UTC
(In reply to Xisco Faulí from comment #28)
> 6-1: https://gerrit.libreoffice.org/#/c/61646/
> 6-1-3: https://gerrit.libreoffice.org/#/c/61654/

Bonjour,

I suppose it means that the fix will be present in 6-1-3 ?

Thank's for that

cordialement,
Comment 31 Mike Kaganski 2018-10-18 09:26:36 UTC
*** Bug 120672 has been marked as a duplicate of this bug. ***
Comment 32 Commit Notification 2018-10-18 10:50:50 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-6-1-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d68ac1325924f7280545e61b7dff0072a959d4ab&h=libreoffice-6-1-3

tdf#119067 DefaultLabel only for interactively created OBJs

It will be available in 6.1.3.

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 33 Mike Kaganski 2018-10-19 09:02:53 UTC
*** Bug 120699 has been marked as a duplicate of this bug. ***
Comment 34 Drew Jensen 2018-10-26 22:11:09 UTC
*** Bug 120947 has been marked as a duplicate of this bug. ***
Comment 35 Bob W 2018-10-27 16:38:09 UTC
I just installed "Version: 6.1.3.1 (x64)
Build ID: a9670562c26181ec3afbe381c9ff499ae88c98b7
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: en-US (en_US); Calc: group threaded" and replicated this same issue of not retaining the desired text in a Label field. This occurs on my Window 8.1 system using the embedded Firebird DB enging.

Immediately after the previous test under 6.1.3, I ran the same report under "Version: 6.2.0.0.alpha1 (x64)
Build ID: ff46ad24d1d3cbcea45895520483ed1fd4ff488b
CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; 
Locale: en-US (en_US); Calc: CL". This run displayed the text I had entered in the Label field. I added additional Label fields, saved report and DB, closed report, and reopened in edit mode. All labels correct. I then reopened in 6.1.3 in edit mode and all label fields display "Label". I close without saving and reopened in 6.2 in edit mode and all label fields displayed the desired text.
Comment 36 Bob W 2018-10-27 16:43:05 UTC
Please see comments this date 10/27/18 below.
Comment 37 moebius20 2018-10-27 17:06:04 UTC
(In reply to Bob W from comment #35)
> I just installed "Version: 6.1.3.1 (x64)
> Build ID: a9670562c26181ec3afbe381c9ff499ae88c98b7
> CPU threads: 4; OS: Windows 6.3; UI render: default; 
> Locale: en-US (en_US); Calc: group threaded" and replicated this same issue
> of not retaining the desired text in a Label field. This occurs on my Window
> 8.1 system using the embedded Firebird DB enging.
> 
> Immediately after the previous test under 6.1.3, I ran the same report under
> "Version: 6.2.0.0.alpha1 (x64)
> Build ID: ff46ad24d1d3cbcea45895520483ed1fd4ff488b
> CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; 
> Locale: en-US (en_US); Calc: CL". This run displayed the text I had entered
> in the Label field. I added additional Label fields, saved report and DB,
> closed report, and reopened in edit mode. All labels correct. I then
> reopened in 6.1.3 in edit mode and all label fields display "Label". I close
> without saving and reopened in 6.2 in edit mode and all label fields
> displayed the desired text.

Bonsoir,
It's just a pre-release dated 2018/10/11 ; so, it means nothing.
see : 
https://download.documentfoundation.org/libreoffice/testing/6.1.3/win/x86_64/

cordialement,
Comment 38 Xisco Faulí 2018-10-29 15:28:08 UTC
*** Bug 121020 has been marked as a duplicate of this bug. ***