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.
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?
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.
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.
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.
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.
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.
(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.
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.
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).
@Ilhan : care to take a look ?
Dear Stephan, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still exists in LO 7.3.3.1 on OpenSUSE 15.3 See also the duplicate, which has just been reported.
*** Bug 148582 has been marked as a duplicate of this bug. ***
Bug is still the same in LO 24.2.2.2 on OpenSUSE 15.6 64bit rpm Linux.