Description: Row protections applied in 7.3.5.2 are not properly retained when the same file is opened in 7.4.0.3 Steps to Reproduce: 1. Open a new blank file in 7.3.5.2 2. Select a few rows and set protection to none 3. Save the file and then open it in 7.4.0.3 Actual Results: ALL the previously unprotected rows have protection turned ON Expected Results: Protection settings should remain exactly as set by the other version. Reproducible: Always User Profile Reset: No Additional Info: Also: Oddly, when the file from 7.3.5.2 is first opened in 7.4.0.3, the protection dialog shows dashes instead of the usual checkmarks in the tick boxes. The sheet behavior is the same as seen when protection is ON.
Adding the specifics: Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Works fine for me, none protection it's respected at opening with: Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL
Having dug a little deeper, I found the following: This seems to be related to the column range difference between the two versions. When opening the file in 7.4, the previously unprotected cells remain unprotected only up to column AMJ (1024). Cells further along, column AMK and beyond have protection turned on. I imagine the response "of course, that's the default". But this leads to functions like right-click / delete row being unavailable. While this can be corrected by the end user, it might not be readily apparent why it's happening. It also might create a lot of work manually reconfiguring multiple workbooks. Maybe that's the only option.
You would think a full-row protection setting would store the range reference as <rownumber>:<rownumber> and ignore columns, which would expand whatever the number of columns available. Adding the meta bug for large spreadsheets.
Some additional information: In an attempt to work around this issue, I have tried the following. Open a new blank workbook in 7.4.1.2 and unprotect an entire row. Protect the sheet then save. Opening that same file in 7.3.6.2. produces the following error: "The data could not be loaded completely because the maximum number of columns per sheet was exceeded". The file has no data yet added to it. There is no data in the "exceeded" ranges. While this is not too surprising, and does not prevent further use of the file, it might be a point of confusion regarding file sharing or exchange between users of these different program versions. Additionally, if the file from 7.4.1.2 is then saved while in 7.3.6.2, the unprotected row is then seen again as protected (i.e. no row delete option) when reopened in 7.4.1.2. So the main point here is that I cannot employ settings that work as expected in both program versions. This is the case even though none of the files contain data in the newly extended ranges. I'm willing to try further tests if anyone has suggestions. Version: 7.3.6.2 (x64) / LibreOffice Community Build ID: c28ca90fd6e1a19e189fc16c05f8f8924961e12e CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Also adding the meta bug for cell protection, bug 107450. (In reply to Daniel Baran from comment #5) > Some additional information: > In an attempt to work around this issue, I have tried the following. > > Open a new blank workbook in 7.4.1.2 and unprotect an entire row. > Protect the sheet then save. > Opening that same file in 7.3.6.2. produces the following error: > > "The data could not be loaded completely because the > maximum number of columns per sheet was exceeded". > > The file has no data yet added to it. There is no data in the "exceeded" > ranges. > While this is not too surprising, and does not prevent further use of the > file, > it might be a point of confusion regarding file sharing or exchange between > users of these different program versions. So this is also an issue for backward compatibility, which I assume would also be solved by referring to column or row ranges when possible if whole columns or whole rows are protected / unprotected. Adding Luboš to CC, hope that's OK?
Dear Daniel Baran, 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
Using the versions listed below, the original bug behavior is mostly unchanged. The one exception is that when the file is saved in 24.8 and then reopened in 7.3, there is no longer display of the previously described error message. "The data could not be loaded completely because the maximum number of columns per sheet was exceeded" That error message only occurs (as one would expect) if data has been entered into the expanded columns (in newer versions). Version: 7.3.5.2 (x64) / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded