== Example == Let's create share\registry\data\finalized.xcu with the following content: <?xml version="1.0" encoding="UTF-8"?> <oor:items xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="o" oor:finalized="true"><value>Example Corp.</value></prop></item> </oor:items> This sets and locks Tools - Options - LibreOffice - User Data - Company. When I open LibreOffice, I see Example Corp., and although I can modify the edit box, the setting is not saved, when I reopen the panel, Example Corp. is there. So far, so good. Then close LibreOffice, and edit registrymodifications.xcu manually. Add an item: <item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="o" oor:op="fuse"><value>MyCompany Ltd.</value></prop></item> Open LibreOffice, and check Tools - Options - LibreOffice - User Data - Company, there will be MyCompany Ltd. And this setting is still locked, i.e. cannot be changed from the UI. == Problem == User can override a finalized setting that is forced on her by company policy, because registrymodifications.xcu is writable by the user. Company name is only an example, presumably every finalized setting can be overridden, and it makes the feature useless.
Hi Janos, thanks for the report. Have you tested this with older versions too? (the report is against 4.2.0.0 master) I recognise the behaviour, but never tested up to changing the registrymodifications.xcu manually. Cor
(In reply to comment #1) I work with master, mainly. But I've just tried and reproduced the problem with LibreOffice 3.5.4.
indeed, XcuParser::handlePropValue (configmgr/source/xcuparser.cxx) does not care about state_.top().locked
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=93210ec3b3e7e773e998a3771136043748232f85 fdo#69027 check for state_.top().locked The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4fb12553f5f273058156026300a715326ec3da2f&h=libreoffice-4-2 fdo#69027 check for state_.top().locked It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This has been fixed, actually.
Just now I was wondering how can I override finalized configuration items without stumbling upon on any other mistake. One should visit http://www.toptenwritingservices.com/essaygeeks-review/ source for help in essays. You have just helped me in overriding my configured items.