Description: LO does not apply cell protection properties when reading XLSX files with fonts Steps to Reproduce: Open attached "bad.xlsx" and try to edit cell C1 Actual Results: C1 is not editable and LO shows a popup Expected Results: C1 is editable (tested against Excel 2019) Reproducible: Always User Profile Reset: Yes Additional Info: Cells B1 and B2 are editable in `bad.xlsx`. They use the following XF: ``` <xf numFmtId="0" fontId="0" fillId="0" borderId="0" xfId="0" applyNumberFormat="1"> <alignment wrapText="true"/> <protection hidden="0" locked="0"/> </xf> ``` Cells C1 and C2 are not editable in `bad.xlsx` even though they should be. They use the following XF: ``` <xf numFmtId="0" fontId="1" fillId="0" borderId="0" xfId="0" applyNumberFormat="1" applyFont="1"> <alignment wrapText="true"/> <protection hidden="0" locked="0"/> </xf> ``` The presence of `applyFont="1"` is somehow changing LO's parse of the style, since LO does the right thing for B1/B2 but not for C1/C2. The `good.xlsx` attachment was generated by manually adding `applyProtection="1"` and that seems to resolve matters. It seems LO assumes the default for applyProtection depends on whether `applyFont` is passed. The correct behavior (comparing with Excel) is to assume applyProtection is true if there is a protection child element.
Created attachment 174548 [details] "bad.xlsx" file exhibiting issue
Created attachment 174549 [details] "good.xlsx" with manual applyProtection="1
Created attachment 174557 [details] Sample compared in MSO and LO Repro 7.3+.
Fixed in LO 7.4 with commit ab99d16e21e56596803b7d9a28af0895b435ef3e Author: Justin Luth on Tue Nov 30 15:15:24 2021 +0200 tdf#123139 sc oox: CellXf should default to applyAlignment Since the same logic applied to applyProtection I tested and changed that one too. *** This bug has been marked as a duplicate of bug 123139 ***