Bug 69027

Summary: finalized configuration item can be overriden by registrymodifications.xcu
Product: LibreOffice Reporter: Janos FARAGO <fari.libreoffice>
Component: LibreOfficeAssignee: Stephan Bergmann <sberg.fun>
Status: CLOSED FIXED    
Severity: normal CC: cno, sberg.fun, xiscofauli
Priority: medium    
Version: 4.2.0.0.alpha0+ Master   
Hardware: Other   
OS: All   
Whiteboard: target:4.3.0 target:4.2.0.1
Crash report or crash signature: Regression By:

Description Janos FARAGO 2013-09-06 11:10:35 UTC
== 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.
Comment 1 Cor Nouws 2013-09-06 11:46:54 UTC
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
Comment 2 Janos FARAGO 2013-09-06 11:53:19 UTC
(In reply to comment #1)
I work with master, mainly. But I've just tried and reproduced the problem with LibreOffice 3.5.4.
Comment 3 Stephan Bergmann 2013-09-06 16:12:23 UTC
indeed, XcuParser::handlePropValue (configmgr/source/xcuparser.cxx) does not care about state_.top().locked
Comment 4 Commit Notification 2013-12-09 11:56:56 UTC
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.
Comment 5 Commit Notification 2013-12-09 12:17:53 UTC
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.
Comment 6 Andras Timar 2014-01-09 13:24:11 UTC
This has been fixed, actually.
Comment 7 Olivia Reed 2020-04-14 05:12:18 UTC Comment hidden (spam)