Connect an Odoo Docker Jet to ONLYOFFICE Docs

This flight plan connects one Odoo database to an existing ONLYOFFICE Docs service. Start it from the Odoo Jet you want to connect. It finds ONLYOFFICE on the same server, checks the connection, installs the available Odoo connector when needed, and saves the connection settings.

It does not create an ONLYOFFICE service or download the connector. The separate ONLYOFFICE Jet template remains usable by other applications.

Before you start

Ask your administrator to confirm the following:

• The Odoo Jet uses Odoo Docker 2.0 (odoo_docker_v2) and runs Odoo 18.0.
• The ONLYOFFICE Jet uses ONLYOFFICE Docs Community (Docker) (onlyoffice_docs). Both Jets are Running, on the same server, with no lifecycle action in progress.
• Both containers are attached to the same Tower Docker Network (tower_docker_network). The plan checks their actual network membership.
• ONLYOFFICE allows connections to private networks. Its onlyoffice_allow_private_ip setting must be true, applied to its running container by recreating it if necessary.
• The ONLYOFFICE Jet has a working HTTPS website address that your users' browsers can reach. Sharing a Docker network does not replace this browser connection.
• The onlyoffice_odoo addon code and its dependencies are already available in Odoo's configured addons paths. This plan supports the parameter schema verified in connector 5.4.0. It checks that schema before making changes.
• Odoo's Odoo DB name (odoo_db_name) identifies the intended database, and Odoo Container Name (odoo_container_name) identifies its running container. Other databases in that container are not configured by this plan.
• The server's ONLYOFFICE JWT Secret (onlyoffice_jwt_secret) matches the secret used by the running ONLYOFFICE container. This is a shared password between the services. Keep it in Settings > Keys and Secrets, never in a normal variable.
• You have a current database backup before installing an addon. Installation adds database objects and can install its required Odoo dependencies.

The connector settings apply to the whole selected database. Running this plan replaces its previous ONLYOFFICE server connection, including a demo connection. It does not change web.base.url, the open-in-same-tab preference, or the connector's internal signing secret.

Import once

1. Import the Odoo and ONLYOFFICE Jet templates first, if they are not already present.
2. Open Tools > Import YAML, upload cx_plan_connect_odoo_to_onlyoffice.yaml, and choose Process.
3. Choose Skip record, then Import. This adds the new flight plan and preserves the existing ONLYOFFICE secret and shared records.
4. Check that the existing secret has the correct value for your server. This package includes its definition for portability, but never includes or changes its value. Use at least 32 letters, numbers, underscores or hyphens.

An imported flight plan is available from Run Flight Plan; it does not change an Odoo Jet's lifecycle or require reinstalling its template. You need Tower Root access to run these database administration commands.

Choose the ONLYOFFICE service

Usually no additional setting is needed. The plan looks for exactly one running ONLYOFFICE Jet on the Odoo Jet's server. Stopped or removed Jets are ignored.

If several services are running, set ONLYOFFICE Jet to connect (onlyoffice_jet_reference) to the intended Jet's Reference. Enter the reference, not its name or website address. You can set it for the Odoo Jet or provide it as a value when running the plan. An explicit reference must identify an ONLYOFFICE Jet on the same server; it is never silently replaced by discovery.

If none or several are discovered, the plan stops before changing the database and explains what to select. It never chooses the first result arbitrarily.

Run from your Odoo Jet

1. Open the Odoo Jet you want to connect.
2. Check its database name and select Run Flight Plan.
3. Choose Odoo - Connect to ONLYOFFICE Docs (connect_odoo_to_onlyoffice).
4. Set the optional ONLYOFFICE Jet reference if needed, then run the plan.
5. Open the flight plan log and check that it finished successfully.
6. Refresh your Odoo browser page, especially after a first connector installation. Open a supported document, make a small edit, save it, and reopen it to confirm the full user workflow with your own permissions and documents.

The four steps shown in the log are:

1. Select and validate Jets: choose the ONLYOFFICE service and check the saved settings.
2. Check readiness: inspect actual networks, addon availability, module state, existing setting names, internal service health, and the shared password. Setting values and passwords are not printed.
3. Install available connector: run only when onlyoffice_odoo is not installed. A missing database module-list entry is refreshed from the available addon code. An already installed module is neither upgraded nor reinstalled.
4. Verify and save connection: check the connector's health, authentication and test-file conversion, then add or update its settings in one transaction. The test conversion checks that ONLYOFFICE can download a file back from Odoo.

The addresses saved for you

| Purpose | Value saved | | --- | --- | | Your browser opens the editor | The ONLYOFFICE Jet's HTTPS website address | | Odoo contacts ONLYOFFICE privately | http://<ONLYOFFICE Jet reference>/ | | ONLYOFFICE downloads files and sends updates to Odoo | http://<Odoo container name>:<Odoo HTTP port>/ | | Services recognize each other | Existing ONLYOFFICE JWT secret and header |

The plan disables the connector's demonstration mode and keeps certificate verification enabled. Internal HTTP traffic travels over the shared Docker network; browser traffic uses the HTTPS address.

Some connector 5.4.0 screens have confusing internal-address labels. The plan uses the actual configuration keys consumed by its source code; do not swap these values based on those labels.

Does Odoo restart?

The plan does not restart the container. It installs through Odoo's immediate module installation API, which tells running workers to reload their registry. It saves settings through Odoo's settings storage API and explicitly tells workers to refresh their caches. Odoo 18 therefore does not require a container restart for these operations. Refreshing the browser loads newly installed client assets.

Installing an addon can briefly interrupt requests while Odoo reloads its registry. Choose a suitable time for the first installation. Later runs skip installation and leave already correct settings unchanged.

If the plan stops

• No ONLYOFFICE Jet / several Jets: start the intended service or enter its explicit reference, then run again.
• Wrong Jet or state: launch from a running Odoo Docker 2.0 Jet, after any other lifecycle action has finished.
• Network mismatch: ask the administrator to attach both containers to the configured shared network. Merely changing a saved variable does not move an existing container. This plan does not recreate either service.
• Addon missing or dependencies missing: add the connector and dependencies to the Odoo image/addons paths first. The plan installs available code into the database; it does not fetch code or install system/Python packages.
• Pending module operation: finish or resolve existing installations, upgrades or removals before retrying. The plan does not take over pending operations.
• Database connection failure: check the database name and Odoo configuration. This plan reads PostgreSQL credentials from Odoo's existing configuration file.
• Authentication failure: ensure the Tower secret and JWT header match the running ONLYOFFICE container. Changing a Tower secret alone does not update an existing ONLYOFFICE container; recreate it through its normal lifecycle.
• Test conversion failure: check private-network access and the Odoo test-file route. If the Odoo container serves several databases, its routing/database filter must select this database when contacted through the internal address. The plan stops rather than saving a connection it cannot verify.
• Installation failure: inspect Odoo's server log for missing dependencies, scheduled-job locks or module errors. A failed install may need administrator attention before a retry.

Configuration is saved only after its connection checks pass. If configuration fails after a successful addon installation, the addon remains installed and the old connection settings remain. If saving succeeds but worker notification fails, the log explicitly says the settings were saved and requests a retry. Fix the reported problem and rerun the plan; installation will then be skipped. A failed plan does not automatically uninstall an addon or restart either service.

Administrator reference

The plan reuses Odoo template variables odoo_container_name, odoo_db_name, odoo_port, odoo_config_file_full_path and tower_docker_network. The config path falls back to /etc/odoo.conf, and the HTTP port to 8069. The config file must be readable by the container's Odoo user and contain its PostgreSQL connection settings. Container/database/network names are restricted to letters, numbers, dots, underscores and hyphens to keep command arguments unambiguous.

The seven managed ir.config_parameter keys are:

| Key | Meaning | | --- | --- | | onlyoffice_connector.doc_server_public_url | Browser-facing ONLYOFFICE HTTPS URL | | onlyoffice_connector.doc_server_inner_url | Odoo-to-ONLYOFFICE internal URL | | onlyoffice_connector.doc_server_odoo_url | ONLYOFFICE-to-Odoo internal return URL | | onlyoffice_connector.doc_server_jwt_secret | Existing shared ONLYOFFICE secret | | onlyoffice_connector.doc_server_jwt_header | ONLYOFFICE JWT header | | onlyoffice_connector.doc_server_demo | Disabled | | onlyoffice_connector.doc_server_disable_certificate | Disabled: verification stays enabled |

Disabled Boolean options are removed using set_param(key, False), as Odoo's configuration API defines. The connector reads absent options as disabled. The installation API and settings commit explicitly signal registry/cache changes; raw SQL is used only for read-only, parameterized inventory queries.

The readiness command invokes two Tower SSH Commands synchronously to read their results and decide whether installation is needed. They use Tower's standard runner, permissions, rendering and secret masking. Its transient values contain no credentials. The JWT travels as a process environment value and is stored in Odoo's connector settings as the connector requires; host/container administrators and Odoo administrators with access to system parameters can access it. It is never written to a host configuration file or printed in the flight plan log.

Installation and configuration pass their Python source in an environment value. A Python subprocess inside the Odoo container supplies that source to odoo shell. The SSH input remains available for Tower to send a sudo password. This supports root, passwordless sudo and sudo-with-password without creating a script file.

Source checks used the local Odoo 18 source (ir.module.module, ir.config_parameter, Registry, and the non-interactive CLI shell) and the connector 5.4.0 source deployed in the Team Odoo container. The original attached Downloads folder is no longer available in this session.

Validation status

Tower accepted and imported the package. Live read-only discovery and readiness checks passed against the running Team Odoo and ONLYOFFICE Jets: connector 18.0.5.4.0 was installed, no existing connector settings were found, both containers shared the expected network, and internal health and JWT authentication passed. The real Odoo shell invocation also passed the connector's health, JWT and Docs-to-Odoo test-file conversion checks, stopping before configuration writes. No connector settings were saved.

Installation and persistent configuration have not been launched on the Team application. These steps are checked against Odoo's source and with local branch checks; a full browser document editing/saving test remains to be performed after you run the plan on the intended Odoo Jet.

The sudo transport regression check reproduced the original password-input failure with both commands. Using Tower's actual sudo command preparation and a simulated password reader, both corrected commands preserved the complete Python source in all three sudo modes and propagated a failing Odoo exit code. The Team server logs in as root, so it cannot provide a live sudo-with-password test.