Collabora Online and Odoo integration: what the module does and where it stops
A team that keeps contracts, quotes and project files in Odoo often wants to open and edit those office files in the browser without downloading them, changing them locally and uploading them again. Collabora's Odoo module, collabora_odoo, is built for that case. It opens and edits office files stored in Odoo, and it uses Odoo user credentials to decide who can open a document, so the access rules already defined in Odoo carry over to the editor. The module requires Odoo 17 and a Collabora Online server that can reach Odoo and can be reached by Odoo. Both directions matter: Odoo must call the editor, and the editor must fetch and save documents back from Odoo, so network paths, DNS names and TLS trust need to be checked in both directions before any user test.
The most important point for a decision-maker is that the module has not yet gone through a security review, according to its own README. That does not mean it is unsafe, but it does mean no independent party has yet examined it, and the organization carries that review work itself. Before production use, the team should decide who reviews the module code, which Odoo and Collabora Online versions are tested together, and how the module is patched when its maintainers publish changes. Note also that Odoo 17.0 standard support ended in September 2026, so a deployment built on Odoo 17 needs a plan for the Odoo upgrade as well as the editor integration.
The integration follows the general WOPI pattern used by other Collabora hosts. Odoo acts as the host that holds the files and answers the editor's requests for file contents and saves, while Collabora Online renders the document in the browser. Odoo decides access from its own users and records, so the first design step is mapping which Odoo groups may open a file and which may edit it. The module does not replace those decisions, and the team should test them with real accounts, including a user who should only view a document. Confirm the exact protocol endpoints and configuration keys with the module README and the Collabora Online documentation rather than relying on this overview.
What you need before connecting Odoo to Collabora Online
The Collabora Odoo module sits between two systems you operate: an Odoo instance that decides who may open a file, and a Collabora Online server that renders and edits it. Each card below is a prerequisite that has to hold on both sides before the first document opens.
Odoo 17 as the target version
The module requires Odoo 17, and Odoo 17.0 standard support ended in September 2026. Confirm the support status of your exact Odoo 17 build against Odoo's standard and extended support documentation before you commit. If your instance is on a newer version, plan a version change first, because the module is not documented for it. Ask Collabora whether a newer branch is planned.
Two-way network reachability
The module needs Odoo to reach the Collabora Online server, and the Collabora server to call back into Odoo to fetch and save files through WOPI. Map both directions across firewalls, load balancers and reverse proxies before installation. Confirm which hostnames each side uses, since a callback to an internal name that the browser cannot resolve is a common failure.
A Collabora Online branch that fits your policy
Choose a supported branch rather than a development build. The 25.04 branch was first released on June 19, 2025 and was still receiving point releases in 2026, and 26.04 was announced on July 23, 2026. Check the release notes for the current point release and any security fixes, and confirm that the Odoo module has been tested against the branch you pick.
TLS on both sides
Serve Odoo and the Collabora Online server over HTTPS with certificates that each side trusts. Browsers load the editor from Collabora, and the WOPI exchange runs between servers, so a certificate that works in one path can fail in the other. Confirm the internal CA chain is installed where Collabora makes its outbound calls to Odoo.
Odoo edition and hosting model
Odoo Community is LGPL-3.0 licensed, while Enterprise source is not public and requires a subscription. Confirm which edition and hosting model you run, because on-premise use of the upgrade service requires an Enterprise subscription. Only the Custom plan can be hosted on Odoo.sh or on-premise, so check your plan before you assume self-hosting is available.
Access model and module review status
The module decides document access from Odoo user credentials, so confirm which groups and record rules should apply to office files before rollout. The module README states it has not yet gone through a security review, so ask for the review status in writing and plan your own testing and sign-off.
How to configure the Odoo module and Collabora Online server
This sequence connects a Collabora Online server to a test copy of your Odoo database, confirms traffic works in both directions, and checks that Odoo user permissions decide who can open and edit each file. Each step ends with a check you can record before anything moves toward production.
Confirm the Odoo version and edition
Confirm that the Odoo instance runs version 17, which the collabora_odoo module requires. Odoo's standard support for 17.0 ended in September 2026, so the team should record that the test environment is outside standard support and that security patches are no longer provided through that channel. Identify the Odoo edition and deployment model, such as Odoo.sh or on-premise, because these determine how you copy databases and apply patches later. Check that the version, edition and deployment model are written down with the name of the person who approved using this version for the test.
Deploy the Collabora Online server
The infrastructure team deploys Collabora Online using Docker, system packages or Kubernetes, based on the team's standard for servers they control. The free CODE edition is positioned for testing and small teams and is not recommended for production, so confirm the edition and support model before the server is shared with business users. Serve the server over HTTPS with a certificate that Odoo trusts. Check that the server answers on its HTTPS address and that its WOPI discovery information is reachable from a browser on the Odoo network.
Install the collabora_odoo module on a test database
Create a test copy of the production Odoo database using Odoo's duplication feature with neutralization, so that no live outgoing messages or integrations run from the copy. Install the collabora_odoo module on the test database only, following the installation steps in the module's README. Review the Odoo server log during installation for dependency or version errors. Check that the module shows as installed in Apps, and that the log contains no errors related to the module after a restart.
Set the Collabora server URL in Odoo
In the test database, open the module's settings and enter the HTTPS address of the Collabora Online server. Confirm the exact setting name and any required format in the module's README, because the value must match the address that the server presents, including the port if you use one. Save the settings and record the value in the change log. Check that the saved value matches the server address exactly and that the setting is still present after you reload the page.
Verify network reachability in both directions
Odoo must reach the Collabora server to open a document, and the Collabora server must reach Odoo to fetch and save file content. The network team tests each direction separately from the relevant host, checking DNS resolution, firewall rules, reverse proxy paths and certificate trust. Confirm that the Odoo URL the Collabora server uses is reachable from the Collabora network segment, not only from users' browsers. Check that both directions return successful HTTPS responses and that the server logs show the test requests arriving.
Open a test document with an administrator
Upload a test .docx file to a record in the test database that an administrator can access. Open the file from Odoo and confirm that the Collabora editing session loads in the browser. Make a small edit, save it, and reload the record to confirm the change is stored in Odoo. Check that the edit session opens, the change persists after reload, and the Collabora server log shows a session for that document.
Test access with one user from each group
Create test users in each Odoo group that should use the editor, along with users who should be denied. The collabora_odoo module decides access using Odoo user credentials, so test against the access rights and record rules you use in production. For each user, open the same test document and record whether the user can view, edit or see nothing. Because the module has not yet gone through a security review, include denial cases and attempts to open files on records the user cannot access. Check that each result matches the expected access in a written test matrix.
Record results before any production decision
Compile the Odoo version, module version, Collabora server version and edition, network test results, and the access test matrix into one record. Mark any failures and the fixes applied. Ask your security team to review the module's code, configuration and access behavior, since the module's README states it has not yet been security reviewed. Check that the record is signed off by the owner of the Odoo instance and the security reviewer before any production database is changed.
How Odoo user access controls who can open and edit documents
The Collabora module uses Odoo user credentials to decide whether a person can open a document stored in Odoo. That means the access model you already run in Odoo, its users, groups and record rules, is the starting point for document access. Treat the document feature as one more consumer of that model rather than a separate permission layer to configure.
- Map the groups first: List which Odoo groups already see the apps and records that hold office files, and note any file attachments that sit on records with broader visibility than their content warrants.
- Check view and edit separately: Confirm for each group whether members should only open files or also change them, and verify both rights with test accounts rather than assuming one implies the other.
- Review record-level visibility: Attachments inherit what the parent record exposes, so check the rules on the source model for each document location.
- Document the decisions: Record which groups receive which rights, who approves changes, and how removed users lose access.
- Avoid finer controls than documented: Do not promise per-file or per-folder permissions unless the module documentation or your own tests confirm them.
Before go-live, ask DeployOpen or your own team to confirm exactly which checks the module performs on each open and save request, and record that answer in the design document.
End users meet access control as a result: a document either opens in the browser editor, opens read-only, or does not open at all. Their experience depends on the groups and rules set by administrators, so unexpected behavior usually traces back to group membership or record visibility rather than to the editor itself.
- Expect the Odoo login: Users open documents with their existing Odoo session, so a user who is signed out or whose account is disabled should not reach a file.
- Read-only is a valid outcome: Some users should see a document but not change it, and they should understand that the restriction is intended.
- Report mismatches: If a user can open a file they should not see, or cannot open one they need, record the record, the user and the group memberships involved.
- Avoid shared logins: Shared accounts make it impossible to tell who edited a file, which weakens any later review.
- Test with real roles: Ask a sample of actual users from each department to open their usual documents and report what they see.
Before rollout, confirm with the users who handle sensitive files that the read and edit behavior matches what the business expects.
Group design is easy to draft and hard to trust until it is tested. Build a test matrix that lists each role, each document location and each action, then run the matrix against Odoo test accounts before any production user relies on it. Use a copy of the database for this work so that test changes do not reach live records.
- Build the matrix: Rows are roles, columns are document locations, and each cell records open, view and edit results.
- Include negative cases: Test users outside the group, users who have left the company, and users with rights in one company but not another if you run multiple companies.
- Repeat after changes: Rerun the matrix after any change to groups, record rules, module versions or Odoo upgrades.
- Use real users for acceptance: Test accounts prove the rules, but a small group of actual users shows whether the design fits daily work.
- Keep the results: Store the matrix with the configuration record so that auditors and future administrators can see what was verified.
When the matrix passes, confirm with the module maintainers and your own security team that no check outside the documented behavior is assumed.
The module's README states that it has not yet gone through a security review. That fact should shape how much weight you give the module's access checks, and it means your own testing carries more of the assurance load.
- Treat the review gap as a risk: Record it in the risk register and decide whether compensating controls, such as tighter Odoo groups and network limits, are required for your data.
- Do not assume deeper controls: Use only the access behavior the module documents, and test anything beyond it before relying on it.
- Limit exposure: Restrict which groups can open or edit sensitive documents, and keep the list of groups short enough to review.
- Plan for upgrades: Odoo 17 standard support ended in September 2026, so access behavior must be retested on any supported Odoo version you move to, and the module's compatibility should be confirmed for that version.
- Ask for evidence: Request the module's current status and any change history from Collabora before approving production use.
Before approving production use, confirm the module's review status, your test results and your compensating controls together in one sign-off record.
Mapping Odoo users, records and attachments to editor sessions
This table compares each Odoo access element with what a Collabora editing session can see and do. Read it as a checklist: the module's README and a test database decide which rows behave as described, and the multi-company and record rule rows need explicit verification before any rollout.
| Odoo element | What the Collabora session sees | What to confirm before rollout |
|---|---|---|
| Odoo user identity | The editing session is tied to the Odoo user credentials that opened the document, per the module README | Confirm in a test database which user identity Collabora receives and that it matches the logged-in Odoo user |
| Access rights (model level) | Read access to the parent model is expected to gate whether a file opens, and write access to gate editing | Test a user with read-only rights and a user with write rights on the same record and record the result for each |
| Security groups | Group membership determines which users can reach the editor, which must be checked against the groups you assign | Confirm group-based restriction works as expected for the Odoo version you run (Odoo 17) |
| Record rules | Record rules filter which records a user can see, so an attachment on a hidden record should not open for that user | Verify record rules are enforced for file open and save, not only for list views; this needs a test case per rule |
| Document attachments | Files attached to a record inherit the access context of that record in the expected design | Confirm whether attachment-level access checks apply separately from the parent record and whether public attachments bypass rules |
| Multi-company databases | Records belong to a company, and a user's active company context can change what they see | Flag for verification: test users who belong to several companies, switching company context, and cross-company attachments |
| Session lifetime and revocation | An open editor session may persist after a user loses rights in Odoo | Test removing access while a document is open and confirm when the session ends or the file becomes read-only |
Security settings and hardening for the Odoo and Collabora link
The Odoo and Collabora link is only as strong as the network path, transport security and patch level around it. The cards below cover the controls that limit which hosts can call Collabora Online, how traffic is protected, how the server stays patched, and how to treat the module's unreviewed status before production.
Restrict which hosts can call Collabora
Collabora Online accepts WOPI requests only from hosts it trusts, so the list of Odoo servers allowed to call it should be explicit and short. Nextcloud's guidance to restrict WOPI requests to the Collabora server IP addresses is a useful pattern to copy. Check the allow list configured on the Collabora side and the firewall rules on the Odoo side, and confirm that both match the same set of addresses after every change to either system.
Use HTTPS for both URLs
Odoo and Collabora should reach each other over the same protocol, and HTTPS is the preferred choice for both the Odoo base URL and the Collabora server URL. Plain HTTP on either leg exposes document content and WOPI access tokens to anyone on the path. Confirm that certificates are valid, that chains are complete, and that any redirects do not downgrade the connection.
Limit network paths to Collabora
The Collabora server needs a route to Odoo and Odoo needs a route back, and nothing else should. Place the Collabora server on a segment that only accepts connections from the Odoo application tier and the users' browsers, and keep its administrative interfaces off that path. Document each open port and direction so the review can compare the design with what is deployed.
Keep Collabora Online patched
Collabora publishes security advisories for Collabora Online, and the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Subscribe to the release notes, map each advisory to the branch you run, and schedule point releases through a tested change window. Also confirm that the package signing keys are current on your RPM or DEB hosts.
Treat the module's review status as a decision
The collabora_odoo module states that it has not yet gone through a security review. That makes it a decision point, not a settled control. Before production, ask for the module source, review its access checks against Odoo's user rights, and commission an independent security review of the module and its deployment. Record the outcome and any accepted risks before the rollout date is confirmed.
Common Odoo and Collabora failures and how to fix them
This table lists the failures teams most often hit when connecting Odoo to Collabora Online, with the likely cause and first fix for each. Use it as a triage sheet, then confirm details in the Odoo logs, the Collabora server logs and the collabora_odoo README before changing production settings.
| Symptom | Likely cause | Fix and where to confirm |
|---|---|---|
| Odoo cannot reach the Collabora server | Firewall, DNS or proxy rules block outbound requests from the Odoo host to the Collabora URL, or the URL points at an internal name Odoo cannot resolve. | Test the Collabora address from the Odoo host, using the same name and port the module is configured with. Open the route in both directions and check the Odoo server log for connection errors. |
| Collabora cannot call back to Odoo | Collabora needs to fetch and save documents through the WOPI endpoints in Odoo. A firewall, reverse proxy or wrong Odoo base URL blocks those callbacks. | Set the Odoo base URL to the address Collabora can reach, allow inbound traffic from the Collabora host to Odoo, and check the Collabora log for failed WOPI requests. |
| Mixed HTTP and HTTPS URLs | Odoo is set to one protocol and Collabora or the browser uses the other. Browsers then block mixed content, and WOPI calls fail or documents open without saving. | Use HTTPS for both the Odoo base URL and the Collabora server URL, and make sure the reverse proxy passes the original protocol. Compare the configured URLs in Odoo and in the Collabora settings. |
| Wrong Odoo version | The collabora_odoo module requires Odoo 17. Running another major version, or a version that has reached end of standard support, can cause the module to fail or stay unsupported. | Confirm the running version under Odoo's About or settings page and match it to the module's README. Odoo 17.0 standard support ended in September 2026, so plan an upgrade path with your Odoo partner. |
| Users see read-only sessions when they expect to edit | Access is decided from the Odoo user's permissions. The user may have read rights on the record but not write rights, so Collabora opens the file in view mode. | Check the user's access rights and record rules in Odoo for the model that holds the document. Test with a known editing user and compare the two accounts. Read-only is the expected result for a view-only user. |
| Certificate trust errors | The Odoo or Collabora server uses a certificate issued by an internal authority that the other side does not trust, or the chain is incomplete. | Install the internal root and intermediate certificates on the Odoo host and the Collabora host, then restart the services. Confirm the chain with an HTTPS client on each host and check the TLS errors in the Odoo and Collabora logs. |
| Documents fail to open after a successful connection | The module and Collabora server are running but the file type, size or session settings do not match what the server accepts. | Check the Collabora server log for the document request and the error code. Test with a small file of each type your users need, and confirm the supported formats in the Collabora documentation. |
Questions buyers ask before connecting Odoo to Collabora Online
What drives the cost and effort of connecting Odoo to Collabora Online?
The effort depends on how many Odoo databases and document types are involved, how the network between Odoo and Collabora is laid out, and how much access control you need beyond the default. Cost has two parts: the people doing the work (your staff, a partner, or both) and the software licences. The Collabora Odoo module is open source, so the module itself has no licence fee, but you still pay for the Collabora server, the Odoo edition you run, and the hours spent on network design, testing and sign-off. Ask any quote to list each of these separately, state what is one-time and what recurs (patching, upgrades, support), and name the Odoo version it assumes.
How long does a test-first rollout take?
Duration depends on your environment, not on a fixed number. A test-first rollout runs on a copy of your Odoo database, so the team can check document opening, editing and saving before users touch it. The main variables are how many network paths must be opened between Odoo and Collabora, whether you already run a reverse proxy with HTTPS, how many document types and user groups need checking, and whether your Odoo instance is already on Odoo 17. Odoo 17.0 standard support ended in September 2026, so if you are not on a supported version, plan the upgrade as a separate track before the integration work starts. Ask for the test environment and sign-off steps to be written into the scope with dates agreed in advance.
Can our team connect Odoo to Collabora Online without outside help?
Yes, if your team has people who can run Odoo on a supported version, operate a Linux server, configure HTTPS and manage DNS and firewall rules. The module's README states that it requires Odoo 17 and that Odoo and Collabora must be able to reach each other, so network work is the most likely gap. Your team should also be able to read Odoo access rules and test them with real user accounts. Be aware that the module has not yet gone through a security review, so an internal team should plan extra review time for security testing before production. Outside help is most useful for the network design, the security review and the cutover plan, and it can be limited to those parts within a fixed-scope agreement.
Does the Odoo edition or hosting model change the integration?
Yes. Odoo Community is open source under LGPL-3.0, while Enterprise is a paid edition with additional features and support, and its source code is not publicly available. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes external API access and custom modules. Odoo Online does not let you run the Collabora server next to Odoo in your own network, so confirm the hosting model first. On-premise use of the upgrade service requires an Enterprise subscription, and Community has no access to that service. Ask your Odoo partner to confirm which edition and plan your deployment needs before you design the network paths between the two systems.
What Collabora Online licensing options are there for this integration?
Collabora Online offers three routes. CODE (Collabora Online Development Edition) is free and rolling, and Collabora describes it as suited to testing, home use or small teams but not recommended for production. For production, the Business plan costs 3 euros per user per month for up to 99 users, according to Collabora's pricing page, and includes long term support, a service level agreement, signed security updates and customer portal access. The Enterprise plan is for 100 or more users and is quoted with volume discounts, adding integration support, customization services and roadmap input. Because the subscription is per user, ask for the user count the quote assumes, whether guest or external users count, and how the price changes if the count grows.
What does the work need from our staff?
Your staff will need to provide an Odoo administrator who can create a test database and confirm user groups, a network or infrastructure owner who can open the required paths and set up HTTPS, and a business owner who can confirm which document types and folders users need. Security staff should review how Odoo credentials decide document access, since the module uses Odoo user credentials for that purpose. Expect to schedule time for user acceptance testing with a small group before wider rollout. Ask any partner to list these roles and the number of hours each one needs in the written scope, so your team can plan its calendar before work begins.
Is the Odoo and Collabora integration ready for regulated production use?
Not without your own review. The module's README states that it has not yet gone through a security review, so treat it as an unreviewed component until someone with the right skills has tested it. DeployOpen can run security testing on applications and APIs and prepare evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those. Before production, confirm the Collabora release line you will run, the patch process for Collabora security advisories, and how access is limited to the right Odoo users and groups.
How DeployOpen scopes and delivers the Odoo and Collabora integration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For the Odoo and Collabora integration, we start from a written scope that fixes the Odoo version, network paths, access rules and handover items before any build work begins.
How we scope
- Confirm your Odoo edition and whether the version you run is Odoo 17, which the module requires.
- Map network paths between Odoo and the Collabora Online server in both directions, including TLS and firewall rules.
- Agree in writing how Odoo user rights will decide document access, and which groups may open or edit files.
How we build
- Install the Collabora Online server and the collabora_odoo module in a staging copy of your Odoo environment first.
- Test open, edit and save flows with office files stored in Odoo, using test accounts for each access role.
- Review the module's security status and record any open risks as items the client accepts or resolves before go-live.
How we hand over
- Deliver configuration documentation covering hostnames, allowed origins, module settings and network dependencies.
- Provide a test script with expected results so your team can repeat checks after upgrades or changes.
- Document the Odoo upgrade and Collabora update steps your team must follow, with the dates you need to plan around.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainers can cover Collabora Online point releases and checks after Odoo major version upgrades.
- Ask for a written quote based on your scope, since DeployOpen does not publish a price list.
