Enhancement Proposal: Configurable Default Save Format (ODF / OOXML)

[pplupo]

This issue is unique.

• I have used the search tool and did not find an issue describing my idea.

Your idea.

Enhancement Proposal: Configurable Default Save Format (ODF / OOXML)

1. Executive Summary & Justification

The choice of default document format — Open Document Format (ODF) versus Office Open XML (OOXML) — creates a fundamental friction point between organizational goals and individual user realities. This specification defines a tiered configuration mechanism, built on the application's existing settings infrastructure, that satisfies three distinct audiences without adding a new subsystem or compromising the core product experience:

• For the Consumer (Market Pragmatism): Out of the box, the software must default to OOXML. The vast majority of unmanaged, individual users operate in a Microsoft-dominated ecosystem. Forcing ODF as a baseline creates immediate Day-1 friction — broken formatting in external communications — and drives users to uninstall the software. OOXML as the compiled-in default ensures maximum market adoption.
• For the IT Administrator (Compliance & Sovereignty): European governments and enterprise institutions deploying this software at scale require the ability to mandate ODF to achieve digital sovereignty and long-term archival compliance. Administrators must be able to set an organizational default across all machines, overriding the consumer OOXML baseline, using the same deployment tooling they already use for other machine-wide settings.
• For the Enterprise (Security & Control): Organizations with strict compliance mandates cannot rely on users voluntarily opting into ODF. Administrators require a Hard Lock that removes the user's ability to override the mandated format, while making the reason visible in the UI rather than silently blocking the toggle.

To resolve these conflicting needs, the application will extend its existing QSettings-based configuration mechanism — the same one that already governs update-check behavior — rather than introducing a bespoke configuration format.

2. Architecture Overview: Cascading Configuration

The default save format is resolved using the application's existing QSettings scope mechanism, the same one used today for CheckForUpdates (Utils::updatesAllowed(), desktop-apps/win-linux/src/utils.cpp:725). No new configuration subsystem is introduced. Two new keys — DefaultSaveFormat and EnforceDefaultFormat — are added to the existing Euro-Office / DesktopEditors registry group already defined by GET_REGISTRY_SYSTEM / GET_REGISTRY_USER (desktop-apps/win-linux/src/defines.h:64-67).

Tier	Mechanism	Location (Linux)	Location (Windows)	Writable by
1 — Application Baseline	Compiled-in constant	N/A (source default: OOXML)	N/A	Nobody (build-time only)
2 — System-Wide Global	QSettings::SystemScope	/etc/xdg/Euro-Office/DesktopEditors.conf	HKLM\Software\Euro-Office\DesktopEditors	Root / Administrator only
3 — Local User	QSettings::UserScope	~/.config/Euro-Office/DesktopEditors.conf	HKCU\Software\Euro-Office\DesktopEditors	Standard user

[ Tier 1: Compiled-in baseline (OOXML) ]
     └── overridden by Tier 2 system-scope QSettings, if set
          └── overridden by Tier 3 user-scope QSettings, if set and not locked

Resolution happens once, at startup, in the same code path that currently builds the settings:init payload (desktop-apps/win-linux/src/prop/cmainwindowimpl.cpp:151-164): the native shell reads both QSettings scopes, computes the effective format and lock state, and includes them in the JSON blob already sent to the CEF renderer via AscAppManager::sendCommandTo(SEND_TO_ALL_START_PAGE, "settings:init", ...). No new IPC channel, file format, or polling logic is required — this reuses the channel the web-apps Preferences controller (web-apps/apps/common/main/lib/controller/Desktop.js) already listens on via editor:config.

3. Scenario 1: The Administrative Baseline & Hard Lock

This scenario defines how IT administrators enforce organizational policy at scale, using the deployment tooling and OS primitives they already rely on for other machine-wide settings — no proprietary installer step is introduced.

3.1 System-Wide Global Configuration

Deployment tooling (MSI/DEB/RPM post-install script, or a config-management push such as Group Policy or Ansible) writes directly to the system scope: /etc/xdg/Euro-Office/DesktopEditors.conf on Linux, the HKLM key above on Windows. This is a plain .ini-style file (QSettings::NativeFormat), editable with any text editor or registry tool:

[General]
DefaultSaveFormat=ODF
EnforceDefaultFormat=false

• Permissions: Enforced by the OS, not the application. /etc/xdg is root-owned and world-readable by default; writing to HKLM requires administrator rights. No custom ACL or install-time permission logic needs to be written.
• Function: Setting DefaultSaveFormat=ODF establishes the organizational baseline, overriding the Tier 1 compiled-in OOXML default for every profile on the machine.

3.2 The Policy Lock (Strict Enforcement)

Setting EnforceDefaultFormat=true in the system-scope file causes the startup resolution step to skip the user-scope (reg_user) lookup entirely — the same short-circuit pattern already used for other admin-controlled flags, just applied one level earlier in the cascade.

• EnforceDefaultFormat=false (or absent): The application applies the administrator's DefaultSaveFormat as a default but still consults the user-scope key, so an individual can override it (Scenario 2).
• EnforceDefaultFormat=true: The application executes a Hard Lock.
  • The resolution step never reads the Tier 3 user-scope key.
  • The settings:init JSON payload includes a locked: true flag alongside the resolved format.
  • In Preferences > Save Settings, the web-apps UI (already listening for this payload via editor:config) disables the format toggle and displays: "Your default save format is managed by your organization."

4. Scenario 2: User Post-Installation Choice

Where administrators have not set a Hard Lock — or for standard consumers who installed the app directly — the individual user retains full control over their default format.

4.1 Local User Configuration

The user-scope file — ~/.config/Euro-Office/DesktopEditors.conf on Linux, the HKCU key on Windows — stores DefaultSaveFormat under [General]. The Preferences UI writes it through the same QSettings::UserScope handle already used for existing per-user preferences (e.g. editorWindowMode); no new persistence path is introduced, and this stays separate from the renderer-owned app.conf JSON blob used for UI state round-tripped via localoptions.

• Permissions: Standard read/write access for the local user — no elevation required.
• Function: Captures the preference set from the application's own UI.

4.2 The Settings UI & Resolution Logic

The user accesses File > Preferences > Save to toggle between "Sovereign (ODF)" and "Compatibility (OOXML)." Changing this toggle writes to the Tier 3 user-scope key described above.

On startup (and on "New Document"), the native shell resolves the effective format as follows:

1. Check Tier 2 lock: Does the system-scope key have EnforceDefaultFormat=true?

• If yes: apply the system-scope DefaultSaveFormat. Stop.
• If no: proceed to step 2.

2. Check Tier 3: Does the user-scope key have a DefaultSaveFormat set?

• If yes: apply it. Stop.
• If no: proceed to step 3.

3. Check Tier 2 default: Does the system-scope key have a DefaultSaveFormat set?

• If yes: apply it. Stop.
• If no: proceed to step 4.

4. Fallback to Tier 1: apply the compiled-in baseline, OOXML.

5. Complementary Enhancement: First-Run Format Onboarding Prompt

This may be the best suggestion to reduce friction with the open-source community in this proposal, but it depends on, at very least, ## 4. Scenario 2: User Post-Installation Choice being implemented.

5.1 Rationale

Tier 2 and Tier 3 are silent by design — an administrator sets a policy, a user changes a toggle, neither requires interaction. But a brand-new consumer install where neither tier has been touched still resolves to Tier 1 (OOXML) without the user ever being told a choice exists. A one-time, dismissible prompt closes that gap: it surfaces the decision at the one moment it's actually relevant (before any document has been created) and then gets out of the way.

5.2 Trigger Condition

Shown once, only when both of the following hold at startup:

• Tier 2 (reg_system) has no DefaultSaveFormat set and EnforceDefaultFormat is not true.
• Tier 3 (reg_user) has no DefaultSaveFormat set yet.

If either an admin default/lock exists, or the user has already made a choice (via this dialog or via Preferences), the prompt is skipped. A new user-scope flag, FormatOnboardingShown=true, is written the first time the dialog is dismissed (in either direction), so it never reappears — even if the user later clears their DefaultSaveFormat back to unset.

5.3 Dialog Copy

Choose your default save format

Compatibility (OOXML — .docx / .xlsx / .pptx)
Best if you frequently exchange files with Microsoft Office users, or your organization already standardizes on Microsoft formats.

Open Standard (ODF — .odt / .ods / .odp)
An open, ISO-standardized format built for long-term archival stability and cross-editor portability — while still opening and saving cleanly to Microsoft formats whenever you need to.

You can change this anytime in File > Preferences > Save Settings.

[ Compatibility (OOXML) ] [ Open Standard (ODF) ]

5.4 Resolution & Persistence

Whichever option is chosen writes directly to the Tier 3 user-scope key (DefaultSaveFormat, same location as §4.1) — the dialog is a UI entry point into the existing resolution logic, not a fourth tier. If the user closes the dialog without choosing, FormatOnboardingShown=true is still recorded (so it isn't shown again) and resolution falls through to Tier 1/Tier 2 as normal on step 3–4 of §4.2.

5.5 Scope Note

This is presented as a separate, optional enhancement to the core cascading-configuration proposal (§§1–4). The tiered resolution logic is fully functional and independently shippable without it; the onboarding dialog only affects discoverability for the unmanaged first-run case.

UI change

This and other artifacts may also have to change because they have file extensions there and may confuse users who have selected a different standard.

[pplupo]

Implemented in: Euro-Office/desktop-apps#36