How to remove a xcu-file from userspace

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

How to remove a xcu-file from userspace

Christoph Lutz
Hi,

I would like to remove the xcu-file
<my_applicationdata>\OpenOffice.org2\user\registry\data\org\openoffice\Office\Commands.xcu
in a programmatic way to ensure, that no user-configuration overwrites the
shared Commands.xcu. Does UNO provide an API to to remove a configuration
ressource from user-space?

best regards,
Christoph
Reply | Threaded
Open this post in threaded view
|

Re: How to remove a xcu-file from userspace

Mathias Bauer
Christoph Lutz wrote:

> Hi,
>
> I would like to remove the xcu-file
> <my_applicationdata>\OpenOffice.org2\user\registry\data\org\openoffice\Office\Commands.xcu
> in a programmatic way to ensure, that no user-configuration overwrites the
> shared Commands.xcu. Does UNO provide an API to to remove a configuration
> ressource from user-space?

No, because this would be a contradiction in itself. If you can set the
protection via API you also can remove it this way (with e.g. a macro),
but a protection against overwriting should be something you can't bypass.

The only working way to prevent modifications on configuration entries
by users is by adding the XML attribute 'oor:finalized="true"' to the
entry in the "share" layer of the configuration. This still needs some
support in the source code so it usually doesn't work for configuration
settings that are changed in an interactive way (like e.g. the position
of a toolbar), but it works for all settings in the "Options" dialog and
- hoorah! - amongst others also for the "Disabled commands" you can
specify in the Commands.xcu.

Best regards,
Mathias

--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [hidden email] is a spam sink.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to remove a xcu-file from userspace

Jörg Barfurth
In reply to this post by Christoph Lutz
Hi Christoph,

Christoph Lutz wrote:
> Hi,
>
> I would like to remove the xcu-file
> <my_applicationdata>\OpenOffice.org2\user\registry\data\org\openoffice\Office\Commands.xcu
> in a programmatic way to ensure, that no user-configuration overwrites the
> shared Commands.xcu. Does UNO provide an API to to remove a configuration
> ressource from user-space?
>

The configuration API Objects in many locations support interface
com.sun.star.beans.XPropertyState (and
com.sun.star.beans.XMultiPropertyState). You can use these to reset
configuration setting to their default values, which amounts to removing
overrides from the user layer of the configuration.

Currently these interfaces don't work recursively on entire trees
(although that would be covered by the service specification), so
resetting data for an entire component isn't easy (you need to walk the
hierarchy and reset locally everywhere).

But if you only want to prevent overrides of your shared Commands
settings, there is an easier way: In the shared Commands.xcu add an
attribute 'oor.finalized="true"' to the root of the part(s) you want to
protect from being overridden. The range covered can be anything from a
single <prop ...>, to the entire <oor:node ...> that defines the component.

As a result these settings (and any settings done on layers preceding
the one where you add the attribute) will be protected from being
overridden by subsequent layers including the user layer. In the API
these settings will appear as read-only now. If there are existing
overrides in the user layer they will be ignored.

Unfortunately there is no API to control the finalized attribute (and
some other similar node attributes), so you have to do this by editing
the configuration file directly.

Ciao, Jörg

BTW: Sun has a configuration manager for StarOffice that allows doing
this through a web-based interface.

--
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         [hidden email]
OpenOffice.org Configuration          http://util.openoffice.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to remove a xcu-file from userspace

Mathias Bauer
Joerg Barfurth wrote:

> Unfortunately there is no API to control the finalized attribute (and
> some other similar node attributes), so you have to do this by editing
> the configuration file directly.

I wouldn't call this unfortunate. Without an API you can make *sure*
that the value is not changed by a macro, Add-On or something else. IMHO
this is important to make the "finalizing" feature useable.

*If* we had such an API we would at least need an access control to it
(or an API that is disabled inside OOo and is only accessible if the
configuration service is used in another environment that supports some
authentication etc.).

Ciao,
Mathias

--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [hidden email] is a spam sink.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to remove a xcu-file from userspace

Jörg Barfurth
In reply to this post by Christoph Lutz
Hi mathias,

Mathias Bauer wrote:

>>Unfortunately there is no API to control the finalized attribute (and
>>some other similar node attributes), so you have to do this by editing
>>the configuration file directly.
>

> I wouldn't call this unfortunate. Without an API you can make *sure*
> that the value is not changed by a macro, Add-On or something else. IMHO
> this is important to make the "finalizing" feature useable.
>

It is stored in a file and a macro, etc. could simply manipulate the
relevant file and then force a reload of the configuration. It gets just
more tedious. But that is unfortunate as it also disallows building
administration tools upon our UNO services. Instead such tools have to
manipulate the XML directly which is more prone to producing files our
services can't read.

> *If* we had such an API we would at least need an access control to it
> (or an API that is disabled inside OOo and is only accessible if the
> configuration service is used in another environment that supports some
> authentication etc.).
>

It is the same as for the shared default values themselves. Currently we
don't have explicit access controls for them. Instead we rely on the
backend to limit access. E.g. for the standard file-based configuration
backend the file system access controls apply. The result is
automatically consistent with control (or lack thereof) of direct access
to the files.

On file systems that support this we install shared files with access
rights that prohibit ordinary users from manipulating them. That would
also prevent these users from removing finalization.

Users that do have sufficient access to the backend can use the
ConfigurationAdministrationProvider to change the default values - even
finalized ones. But they can't remove (or add) the finalized state
itself. To me that is an unfortunate inconsistency. unfortunate.

Ciao, Jörg

--
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         [hidden email]
OpenOffice.org Configuration          http://util.openoffice.org

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: How to remove a xcu-file from userspace

Mathias Bauer
Joerg Barfurth wrote:

> Hi mathias,
>
> Mathias Bauer wrote:
>
>>>Unfortunately there is no API to control the finalized attribute (and
>>>some other similar node attributes), so you have to do this by editing
>>>the configuration file directly.
>
>> I wouldn't call this unfortunate. Without an API you can make *sure*
>> that the value is not changed by a macro, Add-On or something else. IMHO
>> this is important to make the "finalizing" feature useable.
>
> It is stored in a file and a macro, etc. could simply manipulate the
> relevant file and then force a reload of the configuration. It gets just
> more tedious. But that is unfortunate as it also disallows building
> administration tools upon our UNO services. Instead such tools have to
> manipulate the XML directly which is more prone to producing files our
> services can't read.

Of course I assumed that there is no possible write access to the
"share" directory so a direct file manipulation is not possible also.

A manipulation of configuration data in a running OOo instance should
never access anything in the "share" directory of OOo. My choice still
would be to have an API in the configuration service like you want and
disable it in OOo at runtime. OTOH the configuration service in an
administrative tool with suitable access rights could provide this API
access.

Ciao,
Mathias

--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [hidden email] is a spam sink.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]