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.
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.
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
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
*** Bug 119907 has been marked as a duplicate of this bug. ***
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
Could someone change the importance item to « critical» ? Report builder can't be used actually in this state. cordialement,
Given that RB can not be disabled any longer it is a major bug.
*** Bug 120089 has been marked as a duplicate of this bug. ***
*** Bug 120140 has been marked as a duplicate of this bug. ***
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
Bonjour, Unfortunately, still present in LO 6.1.2 final cordialement,
Bonsoir, Given that Report builder can't be used any longer, couldn't the bug be changed from major to critical ? cordialement,
(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
(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...
(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,
*** Bug 120472 has been marked as a duplicate of this bug. ***
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...?
(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 ?
Yes - did that - argh!
*** Bug 120477 has been marked as a duplicate of this bug. ***
Increasing severity due to the number of duplicates...
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
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.
Should be fixed, will check locally
@alg: if it does, given the breakage also happened in 6.1.x, this needs a -6-1 backport...
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
(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,
6-1: https://gerrit.libreoffice.org/#/c/61646/ 6-1-3: https://gerrit.libreoffice.org/#/c/61654/
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.
(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,
*** Bug 120672 has been marked as a duplicate of this bug. ***
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.
*** Bug 120699 has been marked as a duplicate of this bug. ***
*** Bug 120947 has been marked as a duplicate of this bug. ***
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.
Please see comments this date 10/27/18 below.
(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,
*** Bug 121020 has been marked as a duplicate of this bug. ***