Created attachment 170668 [details] An XCD to save to OOXML by default As described at [1], XCD files may be prepared and placed to <INSTALLLOCATION>/share/registry to change common defaults, or to block some settings modifications. The attachment makes OOXML types the default for saving text documents, spreadsheets, and presentations. If copied to C:\Program Files\LibreOffice\share\registry (or renamed to 'd.xcd'), only Writer and Calc settings are applied, not Impress. If renamed to 'a.xcd', it only applies to Writer. If renamed to 'j.xcd', it applies to all three. This is unexpected, and not obvious. Ref: https://ask.libreoffice.org/en/question/211350/force-save-as-ms-office-format-for-all-users/ [1] https://wiki.documentfoundation.org/Deployment_and_Migration#Some_tricks_for_post_deployment_configuration
(In reply to Mike Kaganski from comment #0) > As described at [1], XCD files may be prepared and placed to > <INSTALLLOCATION>/share/registry to change common defaults, or to block some > settings modifications. Not really. If you want to override (non-final) default configuration settings, the .xcd file should go into an extension (and thus be installed into a higher configuration layer than the bottom one, xcsxcu:${BRAND_BASE_DIR}/share/registry, see the CONFIGURATION_LAYERS bootstrap variable in the fundamental ini file). > If copied to C:\Program Files\LibreOffice\share\registry (or renamed to > 'd.xcd'), only Writer and Calc settings are applied, not Impress. > If renamed to 'a.xcd', it only applies to Writer. > If renamed to 'j.xcd', it applies to all three. > > This is unexpected, and not obvious. The default values for those various ooSetupFactoryDefaultFilter props are spread across multiple instdir/share/registry/*.xcd files. In which order those files from one configuration layer are processed is unspecified, and what happens if there are two conflicting settings for a given prop in a single configuration layer is unspecified too.
(In reply to Stephan Bergmann from comment #1) Thanks Stephan - good to know! Maybe you have an idea how to improve that misleading wiki text then, and what would be the preferred location for the XCDs in case when a post-deployment configuration is performed *without* creating extensions (we don't have a tool to create extensions easily from an XCD, right?)?