When a user starts LibreOffice for the first time, the ~/.config/libreoffice/4/user folder is created from the contents of /usr/lib/libreoffice/presets folder. However, if IT puts a customized registrymodifications.xcu file in the presets folder, it is not copied or merged into the "fresh" one that is created. This is true in the two OS's I tested: windows (4.0.0.3) and linux (4.1.1). I don't know if this file is excluded by design or if LibreOffice has already created and opened a fresh config file before beginning to populate the new profile with the presets version (in which case the presets' version would probably fail to overwrite the open file). My expectation is that it would be copied over and not excluded. Since the purpose of the presets folder is to allow IT to define standard configurations and registrymodifications.xcu is the main location of customized configuration settings, I consider this to be a fairly serious bug from a corporate perspective.
This indeed is a very frustrating bug (I assume it is a bug since it seems the registrymodifications.xcu concept should apply at a system level?) It seems as it is there is a "presets folder that doesn't allow one to define their desired presets"? If there is another way to make "system level settings modifications" (of course they can always be overridden if a user has customized them) I would be happy if someone could point me in the right direction.
The current behaviour is by design. LO uses the configuration code before it decides to copy presets to a yet missing user installation. The configuration code would not read registrymodifications.xcu once it has been copied into the user installation (so the currently running LO instance would not use those settings) and, more severely, would overwrite the copied registrymodifications.xcu with only the changes done locally in the running LO instances (and it does do some such changes "behind the scenes" for bookkeeping purposes). The recommended way to install site-wide configuration settings is via an extension that is installed as shared or bundled. (My understanding of the presets folder in general is that it is an implementation detail of LO. It may happen to work to modify existing files in there to install site-wide settings, but to my knowledge that has never been the intent of that folder.)
Seems http://www.linuxtag.org/2012/fileadmin/www.linuxtag.org/slides/Thorsten%20Behrens%20-%20LibreOffice%20configuration%20management%20-%20Tools_%20approaches%20and%20best%20practices.p331.pdf is a good read for LibreOffice configuration management. Also since version 4.2 there is a Windows registry configuration backed available https://wiki.documentfoundation.org/ReleaseNotes/4.2#Windows_Registry_changes.
Created attachment 110748 [details] patch which reads the copied registrymodifications.xcu into the memory copy This patch is against 4.5 master. The code was lifted from migration.cxx and adapted to fit this scenario. By far, the best alternative to "fixing" this is to write a configuration extension. However, that is a HUGE, daunting step for your average sysadmin to take. Documentation is sparse, debugging ability is NIL, intimate knowledge of XML in general and LibreOffice configuration in particular is required. The barrier to entry is extremely high. (I wrote it off as too difficult initially, a co-worker implemented it successfully 'by luck', and even after that I still failed to successfully modify our extension to add another change and gave up after a few hours. I finally got it right the last time I tried.) The proposed bug fix reduces the barrier to entry significantly. An administrator only needs to know about the existence of the .../presets folder. Then they can simply copy a "known good" profile into that location. They don't need to identify the specific XML entries for the settings they want to change, and they don't need to mess with individual's profiles or scripting. (The big downside compared to a config extension is that changes can't be made after a profile already exists, but perhaps you could get away with just deleting individual's profiles, and then they start with a fresh one automatically.) To lower the barrier even further (so a sysadmin doesn't have to know how to properly "prune" his template registrymodifications.xcu file), I'm trying to build in some "sysprep" type of exclusions that should be removed since they don't apply to a default profile (like document history/recovery, personal information, etc.). I think it will be highly beneficial for simple sysadmins (like myself) to have this feature implemented.
Questions and Answers: Q1.) How will this presets patch affect existing installs? A1.) It won't - unless an admin has copied registrymodifications.xcu into presets by accident. If he did, he probably hoped it would be used, and so will be happy when it now starts to work. It will work as he hoped for new users, and will not impact existing users. Q2.) Why is this method needed? A2.) The other methods are either too hard to learn/debug or too cumbersome. This one is extremely simple and elegant. A sysadmin only needs to use the normal LibreOffice Tools->Options interface to design a template profile, and then copy his <home dir>/user profile to <install dir>/presets. Q3.) What method will take priority: config extensions, or presets? A3.) Presets, since it modifies the user's profile. So you could use a corporate-wide standard config extension to manage regular defaults, and add this method for individual machines that need exceptions to the standard. Q4.) What platforms does this support? A4.) All major platforms (not android/IOS - which don't use presets). Q5.) What if a sysadmin wants to change settings that are being excluded? A5.) They will need to use a more complicated method (like config extensions) to manage settings instead of using this simple method. Q6.) What if some new keys are added to LibreOffice that are not included in the list of keys to migrate? A6.) Those preferences will not be imported until a new, higher priority Migration/SupportedVersions profile with migrationsteps is added to officecfg/registry/data/org/openoffice/Setup.xcu. These steps will also be needed to migrate profiles to the next major version of LibreOffice. Q7.) What are the implications of adding the ability to also re-import presets .xcu EVERY time it is updated (instead of only being used to create the first profile). A7.1) It will have no impact unless a sysadmin intentionally updates the contents of the presets folder. A7.2) That would be awesome. It would become a power tool for sysadmins to easily manage adding new/changing existing defaults settings that affect ALL users, without having to delete existing user's profiles. The only users not affected will be those currently running LibreOffice (on multiuser systems), since, when they close LibreOffice, their .xcu will be flushed to disk and so will be newer than the updated preset .xcu. A7.3) Users will lose most of their personally preferences (except excluded ones like recent file history, personnel data) each time a change is made, UNLESS the sysadmin has carefully pruned the .xcu to ONLY include settings he cares about. Alternatively, sysadmins could change the presets .xcu modify time to be "in the past" to avoid affecting existing users.
Created attachment 110824 [details] patch which implements the features mentioned in the Q and A comment 5
This proposed patch was not accepted because "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." Find out more about using the "official way" of creating a configuration extension at https://wiki.documentfoundation.org/Extensions If you would also like to have this proposed method adopted, add yourself to the CC List and vote it up in a comment.
I have been trying to apply a modification to the registrymodifications.xcu to user profiles so that users can authenticate everytime they print from libreoffice. As described here, an easy and logical mechanism to do so would be to push a registrymodifications.xcu from the preset folder. We do not have the time nor resources to develop an extension. Voted up.
What you can do if you're fine with manually manipulating a LO installation anyway is to create a share/registry/data directory and drop such a registrymodifications.xcu (or any other name, ending in .xcu) there. Any .xcu files in share/registry/data are read after all the normal default configuration .xcd files in share/registry, on every start of LO.