Bug 167148 - UNO API of sheet protection XProtectable must consider loext:table-protection attributes
Summary: UNO API of sheet protection XProtectable must consider loext:table-protection...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-21 14:55 UTC by migs
Modified: 2025-06-21 14:58 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description migs 2025-06-21 14:55:10 UTC
The introduction of new loext:table-protection attributes to the ODS format in:
https://bugs.documentfoundation.org/show_bug.cgi?id=147034 1

Does not seem to have considered also modifying the oSheet.protect() method to pass additional parameters.

The attributes are set in context.xml:
<table:table table:name=“Sheet1” table:style-name=“ta1” table:protected=“true”><loext:table-protection loext:select-protected-cells=“true” loext:select-unprotected-cells=“true” loext:insert-rows=“true” loext:use-autofilter=“true”/>

The new attributes are causing a serious regression of functionality since now the default behavior of sheets with autofilter is to disable the use of filters when the sheet is protected.
In our case, we have dozens of spreadsheets that rely in autofilter that are now suddenly disabled because we protect them prior to passing to users.

The UNO API of sheet protection (com.sun.star.util.XProtectable interface) should consider passing the new loext attributes to restore functionality.
Comment 1 migs 2025-06-21 14:58:44 UTC
I meant to say that:
The UNO API of sheet protection (com.sun.star.util.XProtectable interface) should consider passing the new loext attributes.
Currently there is no way of programmatically change the loext attributes of <table:protected="true"