# Why doesn't registrymodifications.xcu in the presets folder get distributed to a new user? [closed]

A nice feature for defining default settings for a new user is the folder %ProgramFiles%\LibreOffice 4\presets. When LibreOffice is started for the first time, the contents of this folder are copied to %appdata%\Libreoffice\4\user if that folder doesn't already exist. (This also works with at least some versions of 3.x). So at installation time, IT can customize standardized settings to be distributed to their users. HOWEVER, the main source of LibreOffice settings is in the file registrymodifications.xcu, and for some reason if you put a customized registrymodifications.xcu file in the presets folder it IS NOT copied along with all of the other files. (I'm assuming that LibreOffice already has opened an empty one before the folder is copied over, and so it can't overwrite the essentially blank one).

Information about pre-configuring LibreOffice user settings is very scarce, but it seems like a general consensus is to write a script to store a customized registrymodification.xcu settings file somewhere, and then copy it into a users profile before starting LibreOffice. Since that mechanism is already there conceptually with the presets folder, I'm surprised I haven't seen any discussion about why presets works with everything except this all important file! I suggest that the presets code should be modified to allow this file either to be copied first (before starting the blank one) or else merging the two together.

Side note: My preferred method so far of customizing settings is to modify the system defaults in %ProgramFiles%\LibreOffice 4\share\registry\*.xcd files. That has worked well for windows installs since I control when upgrades occur, and simply run the xmlstarlet script after every upgrade to re-apply my customizations (because every upgrade replaces all of the share\registry\*.xcd files). See http://itconnect.info/forum/topics/libreoffice-settings-to-change-from-the-defaults/ for more details and the script.

However, with Linux I'm leaning towards letting the OS handle upgrades (since that is much more in fitting with Linux package management mentality) and thus I need a different method of ensuring that the settings default properly for each user. The PRESETS folder seems like it would be ideal as the alternative method if it fully worked. I've only seen vague references to another alternative - using extensions to manage setting changes. However, identifying and creating the correct settings files sounds very complicated to me - much ...

edit retag reopen merge delete

### Closed for the following reason question is not relevant or outdated by Alex Kemp close date 2015-10-04 22:52:02.642403

1

I too have been baffled by why the "presets" registrymodifcations.xcu isn't distributed to newly created users. As the question is asking, how indeed are we supposed to roll out some customized settings to a group of newly imaged machines (that don't have the user profiles created yet)? It seems like the process in in place, but yet others are custom hacking their own copy scripts to handle the issue (I have also seen references to this online: not elegant esp. if a presets folder exists).

( 2013-09-18 12:56:01 +0200 )edit
2

I submitted a bug regarding this issue: https://bugs.freedesktop.org/show_bug.cgi?id=69609

( 2013-09-20 16:57:02 +0200 )edit

A patch is attached to bug fdo#69609 adds this support. However, LIbreOffice decision makers are undecided on accepting the patch. "On the one hand, I see the demand to make things simple. On the other hand, we already have a well-established way to do this with extensions. The presets folder and registrymodifications.xcu have never been advertised as modification vectors. 'Officially' introducing this additional way of making modifications would mean more places where we need to take of."

( 2014-12-29 09:35:39 +0200 )edit

Find out more about using the "official way" of creating a configuration extension at https://wiki.documentfoundation.org/E...

( 2015-01-25 18:59:28 +0200 )edit