Bug 131664 - REPORT-BUILDER: Attribute "Auto Grow" will only be saved if first field of a row is set to "Auto Grow" → 'Yes'
Summary: REPORT-BUILDER: Attribute "Auto Grow" will only be saved if first field of a ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 148582 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-03-29 13:37 UTC by Stephan
Modified: 2024-04-16 06:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot from report with overflow happening. (127.38 KB, image/png)
2020-04-11 13:34 UTC, Stephan
Details
Open the report and change label-field "Memo" to Auto Grow → No (9.66 KB, application/vnd.oasis.opendocument.database)
2020-04-11 14:56 UTC, Robert Großkopf
Details
Report Layout (223.91 KB, image/png)
2020-04-11 17:35 UTC, Stephan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan 2020-03-29 13:37:52 UTC
Description:
I have designed a report in LibreBase, where two fields shall auto-expand in case there is more content than would fit in the designed bounding-box. When setting the "Auto Grow" attribute of the fields to "Yes", the generation of the report yields the expected result. However, after saving and reopening the reports the attribute is reset to "No" for both fields.

Steps to Reproduce:
1.Generate Report
2.Design Fields and set attribute "Auto Grow" to "Yes"
3.Save Report
4.Reopen Report and check attribute "Auto Grow"

Actual Results:
Attribute "Auto Grow" reverts to "No".

Expected Results:
Attribute "Auto Grow" should stick to "Yes".


Reproducible: Always


User Profile Reset: No



Additional Info:
The generated report of course also doesn't auto grow the fields, so text gets truncated.
Comment 1 Robert Großkopf 2020-04-11 12:49:52 UTC
Couldn't confirm the buggy behavior. Have tested it with
LO 6.4.3.2 on OpenSUSE 15.1 64bit rpm Linux.

The automatic row height has been added for LO 6.4. So could be the bug has gone since 6.4.0.3. Could you try a newer version?
Comment 2 Stephan 2020-04-11 13:34:10 UTC
Created attachment 159487 [details]
Screenshot from report with overflow happening.

The behaviour is still present in LO 6.4.2.2 (which seems to be the latest version for MacOSX). I just installed, set "Auto Grow" to "Yes" and saved the report. After closing the report from edit mode and executing it again, the red triangles indicating overflow are still there.
Comment 3 Robert Großkopf 2020-04-11 14:56:17 UTC
Created attachment 159488 [details]
Open the report and change label-field "Memo" to Auto Grow → No

Have tested it a little bit more.
When I execute the report while the report is open for editing the auto grow will work.
Then I closed the report-editor and started again and the field won't be set to auto grow.
Then I set the label-field, which is the first field of the row, to auto-grow and the auto-grow will work like it should.
Seems to me the first field in a row had to been set to get the auto grow working while the report isn't opened for editing.

Pleas test the attached database.
Execute the report - all content could be seen.
Edit the report and set the label "Memo" to Auto Grow → No. 
Save the report, close the report and start it again.
The fielkd for the content, not only for the label, won't auto grow.
Comment 4 Stephan 2020-04-11 17:35:24 UTC
Created attachment 159493 [details]
Report Layout

I took your workaround and applied it to my report. In my report, only the fields "Task Description" and "Task Source" may be larger than the reserved space. The other fields will not ever overflow. 

Now however, I set the "Task Number" field (not the label in the header) "Auto Grow" -> "Yes" (also the other fields) and after saving the report, the attribute remains set to "Yes" and the report can be executed any time now, without having to manipulate the arribute "Auto Grow" every single time. So for the time being I am happy.

I still think, it remains a bug. I would like to keep authority on which fields are allowed to "Auto Grow" and which ones not. Now "Task Number" can "Auto Grow" which wouldn't be necessary.
Comment 5 Robert Großkopf 2020-04-11 17:47:47 UTC
Have changed the title to reflect the problem:

I could chose Auto Grow → Yes for a field while editing a report.
It will work right during the report is opened for editing.

After saving and closing the report it will only work if I had chosen the first field of a row Auto Grow → Yes. 

The value for the first field in a row will be saved for all fields of a row while saving the report.

Expected behavior: Value for Auto Grow should be saved for every single element.

Tested with LO 6.4.3.2.2 on OpenSUSE 15.1 64bit rpm Linux.
Comment 6 Stephan 2020-04-11 17:57:00 UTC
Actually, I tested to set the first field to "Auto Grow"->"Yes" and left all other fields to "No". After saving and executing the report, the fields set to "No" did overflow with the red triangle shown. Only after setting them to "Yes" and saving (which is then successful to make the "Yes" stick) the report worked as intended.
Comment 7 Robert Großkopf 2020-04-11 18:39:15 UTC
(In reply to Stephan from comment #6)
> Actually, I tested to set the first field to "Auto Grow"->"Yes" and left all
> other fields to "No". After saving and executing the report, the fields set
> to "No" did overflow with the red triangle shown. Only after setting them to
> "Yes" and saving (which is then successful to make the "Yes" stick) the
> report worked as intended.

Did you test it with the attached database? I tried it again and again. I 'm not able to save "Auto Grow" → "No" for the second field if the first field is set to "Yes". I could execute it right way while opened the Report Builder for editing and will see the red arrows, but when it is saved and closed and I execute the report auto grow will be executed for all fields in the row. Reopened for editing the report and the field I set to "No" is opened with the property "Yes" for "Auto Grow".

If this isn't the bug you have detected I will set this one back to unconfirmed and open a new bug. Seems we have detected different behavior on MAC and Linux system.
Comment 8 Stephan 2020-04-12 15:12:24 UTC
The database you provided opens with the "Name" Label and Field "Auto Grow" set to "No". The "Text" and "Memo" Label and Field "Auto Grow" are set to "Yes".

I first changed Text Label and Field to "No", saved and reopened. Both stayed "No". Then I changed Memo Label and Field to "No", saved and reopened. Also those stayed set to "No".

However, when I change one of the Labels to "Yes", the Field automatically inherits the "Yes". When I set the Field to "No" and save, it will not stick. After reopening it will again show "Yes". So it seems, the Label governs the Field in that respect. 

Since mostly the Labels will be in the page header section, the formatting of the Fields should be independent from the Label. Or at least LO creates the false impression, that one can set the "Auto Grow" attribute of the Field, which in fact you can do but after saving and reopening it will reflect the setting of the Label again.
Comment 9 Alex Thurgood 2020-04-15 13:34:11 UTC
This would indeed be a bug by most user's standards, as the behaviour is unexpected in relation to the choice of field selected to autogrow.

No doubt, as Robert has mentioned, this could be to do with an incompletely implemented part of the code that was introduced when this feature was developed (unless some other change has accidentally broken this functionality since then).
Comment 10 Alex Thurgood 2020-04-15 13:37:41 UTC
@Ilhan : care to take a look ?
Comment 11 QA Administrators 2022-04-16 03:51:44 UTC Comment hidden (obsolete)
Comment 12 Robert Großkopf 2022-04-16 05:46:43 UTC
Bug still exists in LO 7.3.3.1 on OpenSUSE 15.3
See also the duplicate, which has just been reported.
Comment 13 Robert Großkopf 2022-04-16 05:47:43 UTC
*** Bug 148582 has been marked as a duplicate of this bug. ***
Comment 14 QA Administrators 2024-04-16 03:16:12 UTC Comment hidden (obsolete)
Comment 15 Robert Großkopf 2024-04-16 06:14:37 UTC
Bug is still the same in LO 24.2.2.2 on OpenSUSE 15.6 64bit rpm Linux.