Hi Brian,
Brian Raymond wrote:
On 4/5/05 8:38 AM, "Joerg Barfurth" <[EMAIL PROTECTED]> wrote:
You can restrict access to individual settings by providing a configuration data (.xcu) file and using the protection attributes (oor:finalized and oor:mandatory) in that file to mark individual settings or entire subtrees as protected from further (e.g. user) modification.
If you deploy your component with its configuration data as a shared UNO package, this data is imported into the basic OOo installation structure and should generally end up in a file that is not user-writable.
You can't currently manipulate the access control attributes via the API. Manipulating protected data via the administrative API should leave the protection in place.
It's been a few weeks but I wanted to catch up on this again.
Can you expand on what you are referring to when you state protected
attributes can be modified via the "administrative API"?
Using the service "com.sun.star.configuration.AdministrationProvider" you can use the OOo API to write to configuration layers other than the user-specific one. You need to provide an 'entity', which is a token that identifies the layer to write to. For file-based data this is a file URL to the base directory of a layer.
Even this interface currently does not support changing (or even quering) the protection status of items on that layer. But as protection has an effect only on subsequent layers, you can change values even for settings which are marked as protected or are part of a subtree marked as protected in the current layer (but not on prior ones). Thus, if you set up an initial layer file that marks a subtree as protected, you can subsequently use the API to manipulate values in that file while preserving the protected state.
Note: If you deployed your xcu file using the UNO package manager, then writing to that layer does not work well. Firstly the deployed files are 'owned' by the package manager and there are package manager operations which regenerate the effective files from the unmodified packages, thus losing your changes, and secondly you need to find out the correct file URL in the first place, which in OOo 2.0 includes a random directory name created by unopkg.
I'm adding the configuration data via an .xcu file now so I'm going to experiment with the finalized/mandatory settings. I need to provide an "administrative UI" to allow edits by admins however I'm not clear on how I can separate the two.
Using this AdministrationProvider API has some advantages in that it manipulates the data with correct semantics, but may be difficult to set up so that it works correctly. This interface is/was used in OOo 1.x to change default values during setup, but isn't well-tested in OOo 2.0 or for other purposes.
Ciao, J�rg
-- Joerg Barfurth Sun Microsystems - Desktop - Hamburg >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<< Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
