文档在线预览这件事，在Odoo里一直是个让人又爱又恨的话题。爱的是Odoo本身把附件管理、文档存储和权限模型都做得相当完整，恨的是自带的预览功能实在简陋，碰到DOCX、XLSX这种复杂格式，基本就是让用户“下载、打开、再看”三步走，效率低到让人怀疑人生。我早前在某公司做内部系统时，被销售团队投诉过无数次“合同附件预览太慢”“批量查看报价单要点十几次鼠标”，后来把ONLYOFFICE接进Odoo之后，这个问题才算真正落地解决。

这篇文章不聊虚的，直接从我实际部署和维护的经验出发，把ONLYOFFICE与Odoo集成的架构逻辑、部署步骤、配置细节、权限映射、问题排查这些干货一次讲透。不管你是刚接触Odoo的新手，还是已经在生产环境里跑了一段时间想优化方案的老手，这篇文章都适合你。我会把那些文档里不会写的坑和心得也一并放进来。

1. 集成架构全貌：从“文件预览”到“在线协同”

1.1 为什么偏偏是ONLYOFFICE

Odoo里能用的文档预览方案其实有好几条路。最简单的是Odoo自带的附件预览，本质是通过浏览器内置的PDF预览能力来实现，遇到PDF文件还能凑合用，但遇到Office格式就直接抓瞎。另一条路是把文件转成PDF再预览，社区里也有不少模块做这件事，问题是转换有延迟、格式会错乱，而且只解决“看”的问题，解决不了“改”的需求。

ONLYOFFICE在这几个方案里算是平衡点最好的一个。它是真正的Office文档在线编辑套件，部署形态是一个独立的文档服务，Odoo通过HTTP API把文件内容、权限信息、回调地址交给这个服务，用户在浏览器里直接看图、编辑、保存，整个过程文件始终在服务端流转，浏览器只是一个渲染终端。这套架构最大的好处是：预览质量和Office原生渲染几乎一致，编辑能力是完整的，不是那种“让你打个字都卡半天”的半吊子编辑器。

从项目落地角度讲，ONLYOFFICE还有一个优势——它跟Odoo官方有专门的集成模块，意味着你不需要自己从零写API对接，只需要把模块装好、把服务器地址配上，剩下的由两者自己协商。这个“半官方”的身份让它的生命周期和升级节奏都比较稳定，至少比那些个人维护的第三方模块靠谱得多。

1.2 整体架构与请求链路

很多人第一次看ONLYOFFICE集成时，容易被“两个服务”这个概念绕晕。我画个文字版的链路帮助理解：

• 用户浏览器访问Odoo后台，点开某个附件。
• Odoo在前端界面里发现这个附件是Office格式，于是加载ONLYOFFICE的JavaScript API，并生成一个带有文件信息和用户信息的配置对象。
• 浏览器拿着这个配置对象，去请求ONLYOFFICE Document Server的页面，Document Server根据配置里的文件URL去Odoo那边拉取文件内容。
• 用户编辑完成后，Document Server通过回调URL把新内容推回Odoo，Odoo负责把文件写回附件存储。

也就是说，真正存文件的地方始终是Odoo，ONLYOFFICE只是一个“渲染+编辑”的外包服务。理解这条链路对排查问题极其重要，后面讲排障时会反复用到这个模型。

1.3 两种“集成”的正确理解

在社区里你会看到“ONLYOFFICE Odoo集成”有时候指两件不同的事：

第一种是官方模块级的集成。Odoo默认支持通过模块商店安装ONLYOFFICE官方提供的模块，这个模块让你可以在Odoo的文档附件上直接预览、编辑Office文件。大部分人的需求是这种。

第二种是把Odoo已经存储的文件作为数据源，在ONLYOFFICE里打开，或反过来把ONLYOFFICE编辑的内容回传给Odoo。这种更像定制开发场景，需要你自己写一些桥接逻辑。

本文重点讲第一种，也就是开箱即用的官方集成路径，同时会补充一些在此基础上做二次开发的思路。

2. 环境准备与核心组件选型

2.1 组件清单与版本对应关系

部署前先把组件列清楚，避免后面版本打架：

一个最小可用环境包含三块：

• Odoo服务器。无论你是社区版还是企业版，版本不要太过时，我用的是Odoo 17测试环境，Odoo 15/16也都行，但老版本要留意模块兼容性。
• ONLYOFFICE Document Server。这是核心，它本身是一个Debian系或RPM系的服务器软件包，装好后会启动一个Web服务，默认监听80端口，同时内置了PostgreSQL和RabbitMQ作为自己的内部依赖。
• 浏览器。这个看起来废话，但版本别太老——ONLYOFFICE前端用了不少现代特性，IE和古老Chrome会直接白屏。

版本对应关系上，我的建议是：优先用两边最新的稳定版。Odoo官方模块和ONLYOFFICE Document Server的耦合度不算高，新版模块通常能兼容多个版本，反而是旧版模块配新服务会出现一些莫名其妙的问题。

2.2 一台服务器还是两台服务器

生产环境建议把Odoo和ONLYOFFICE文档服务分开部署。原因很现实：

• Odoo是应用服务器，吃内存和CPU主要在业务计算上；ONLYOFFICE Document Server在多人同时编辑时CPU占用会直线上升，两者混布容易出现“你抢我的CPU，我拖你的响应”的场面。
• 安全边界更好区分。文档服务如果被单独暴露（哪怕只在内网），攻击面也是可控的；如果和Odoo混在一起，一旦文档服务被拉穿，影响面会扩大。

测试环境当然可以一台机器全都装，省事。但我仍然建议用Docker方式隔离跑Document Server，后面升级和维护都会方便很多。

2.3 ONLYOFFICE Document Server的部署方式

ONLYOFFICE官方提供了两种主要安装途径：一种是直接用Debian/RPM包安装到系统，另一种是使用Docker镜像。我在实际项目中推荐Docker方式，不是说裸装不行，而是Docker方式有几个明显好处：

• 升级方便。换一个image tag、重启容器就完事。
• 依赖干净。Document Server自带的PostgreSQL、RabbitMQ、Nginx等组件不会污染宿主机环境。
• 网络隔离容易。通过docker network可以控制它只能访问Odoo和必要的出口地址。

下面是基于常见实践整理的Docker启动命令（以官方镜像为例）：

docker run -i -t -d -p 80:80 \ --name onlyoffice-document-server \ --restart=always \ -e JWT_ENABLED=true \ -e JWT_SECRET=your-strong-secret-key \ -e JWT_HEADER=Authorization \ -v /data/onlyoffice/logs:/var/log/onlyoffice \ onlyoffice/documentserver:latest

补充几个命令参数的说明：

• 端口映射。生产环境不要直接映射80到宿主机80，建议映射到某个高位端口如8008，前面加Nginx反向代理。
• JWT相关参数。这个是安全关键，ONLYOFFICE 7.2之后默认强制JWT，如果Odoo那边配置的密钥不一致，就会出现“权限校验失败”之类的错误。密钥一定要用足够长的随机字符串，不要用123456。
• USB端口可以去掉，文档服务不需要它。

装完之后在浏览器访问http://<文档服务器IP>:<端口>/healthcheck，如果返回结果包含类似“true”的健康检查响应，说明服务基本起来了。这里的返回可能因版本略有差异，重点是HTTP状态码200。

2.4 Odoo侧模块安装

Odoo侧需要安装ONLYOFFICE模块。在Odoo 17里，这个模块在Apps商店中可以直接搜到，名字通常是“ONLYOFFICE”，安装后会在“设置-常规设置-集成”下出现文档服务配置项。

如果你的Odoo无法联网访问应用商店，也可以下载模块包（zip格式）放入addons目录，然后在“应用”界面通过“更新应用列表”扫描出来。这里有个常见的坑：模块对Odoo版本是有校验的，强行安装在匹配的版本上会导致加载时直接报错，看Odoo日志会提示模块的manifest文件版本不兼容。

装完之后先别急着配置，先在系统层面确认两件事：

• Odoo能否访问Document Server的地址。
• Document Server能否回访Odoo的地址。

如果两边在内网，确认网络策略开放了端口即可。如果涉及跨网段、防火墙或公网部署，这一步就要仔细点，不要漏掉。

3. 配置核心参数与集成细节

3.1 文档服务地址与服务入口

模块安装完成后，在Odoo设置里找到ONLYOFFICE的配置页面，比较关键的一项叫“Document Server Address”，填的就是Document Server对外提供服务的完整地址。比如：

http://172.16.10.20:8008

这里有个细节容易踩坑：Odoo前端会把浏览器地址栏里的访问地址发给Document Server，Document Server在初始化页面时需要加载自身的JS和CSS，如果这个地址配置成Odoo自己的地址，或者配置成Document Server内网不通的地址，页面会加载不出来。

换句话说，这个配置项应该填浏览器能访问、同时Document Server自身也能访问的地址。稳妥起见，生产环境会配置一个域名或统一网关入口，例如：

https://docs.internal.example.com

3.2 密钥与JWT机制对齐

前面提到Docker启动时给Document Server设置了一个JWT密钥，Odoo侧也需要配置完全相同的密钥，否则集成模块发出去的签名字段在Document Server那边验证不过去，表现为“打开附件时提示FORBIDDEN”或者直接看不到预览界面。

Odoo配置页里和密钥相关的字段叫“Document Server Secret”。把Document Server的JWT_SECRET填进去，两边对齐即可。

关于JWT，再补充一点个人经验：ONLYOFFICE的JWT校验粒度比较细，它会对几种不同类型的请求分别签名，有些请求用Header携带token，有些在JSON Body里携带token。Odoo官方模块已经把这些细节处理好了，我们自己的二次开发如果手动拼请求，很容易漏掉签名，到时候报401都不知道去哪里查。因此能走官方模块就不要自己实现JWT拼接，减少很多无谓的调试成本。

3.3 可预览/可编辑的文件类型与生效场景

ONLYOFFICE在Odoo模块里的集成重点覆盖Office格式，这也是它最有价值的地方。

• DOCX、XLSX、PPTX是主战场，预览和编辑都支持。
• ODT、XLS、PPT等历史格式也可以打开，兼容性看具体版本。
• CSV可以打开预览，但编辑后回调保存可能不如原生的XLSX平滑。
• PDF在某些版本里支持预览，但不一定支持编辑。

这个矩阵对需求澄清非常重要。很多业务方会说“我要所有附件都能在线编辑”，但实际大多数文档都是PDF和图片，真正需要在线改的其实是合同模板、报价表、演示文稿这几类。提前和业务方把格式边界说清楚，项目就不会在验收时拉扯。

在Odoo的实际使用场景里，集成模块并不仅仅作用于“附件”一个地方。当你在任意模型里挂了附件（比如工单、订单、合同），只要满足格式条件，ONLYOFFICE预览就会自动接管附件列表里的文档。这比单独做一个“文档管理”应用要省事得多，因为Odoo所有业务模型都天然具备附件能力，这份能力直接全覆盖。

如果你希望更进一步，比如在某个自定义模型里直接展示可编辑的文档面板，还可以配置使用自带“文档预览窗口”组件，这样用户点击文档后直接在页面内弹出编辑区域，而不是跳转到单独的编辑器标签页。这个交互在小屏幕适配和多文档切换时会更好用。

3.4 回调URL与文件保存链路

在线编辑之所以能保存，依赖的是Document Server向Odoo发起的回调。模块配置页里的“Callback URL”一般会自动生成，指向Odoo自身的某个路由，格式类似：

/onlyoffice/callback

前面讲请求链路时说过，Document Server先通过Odoo给的下载URL拿文件内容，用户编辑完成后再通过这个回调URL把新内容传回来。因此，Odoo必须允许Document Server访问这个回调地址。如果Odoo做了IP白名单或登录限制，需要把Document Server的服务器IP加进去。

回调保存失败的症状很典型：用户在ONLYOFFICE编辑器里看到“已保存”提示，但回Odoo下载附件，内容还是旧的。排查时直接查看Document Server的日志，里面会有HTTP状态码，如果出现401或403，大概率是JWT密钥不对；如果出现404，大概率是回调路由被某种重定向或代理规则吞掉了。

3.5 多Odoo实例共享同一Document Server

有些中大型部署是Odoo多实例（多个数据库、多套环境共用一套服务），这时候我建议不要盲目共享同一个Document Server。原因在于JWT密钥只有一个，如果多个Odoo实例的密钥不一致，就会互相串。如果所有实例都配相同密钥，安全性又下降，因为一个实例的密钥泄露意味着所有实例的文档接口都暴露。

稳妥做法是：每个环境准备独立的Document Server，或者至少保证生产环境独享一套服务。测试、预发、生产最好各归各，省得“测试环境改配置把生产也带歪了”这类事故。

4. 安全边界与权限模型

4.1 文件权限是怎么映射的

Odoo有非常严密的记录级权限体系。ONLYOFFICE集成模块会把当前Odoo用户信息和权限状态带到Document Server的编辑器配置里，具体包含：

• 当前用户是否有该附件的读权限。如果没有，Odoo文件列表里压根就不会出现预览入口。
• 当前用户是否有该附件的写权限。如果有，编辑器开放编辑工具栏；如果没有，只保留查看模式。
• 当前用户是否有下载权限。这部分会影响Document Server侧对复制、下载等操作的控制。

需要明确的是，ONLYOFFICE自身也有一套用户管理概念，但集成模式下它更多是“接受宿主系统的身份信息”，并不创建独立的用户体系。换句话说，Odoo是唯一权威的身份源，Document Server只是执行者。

这里有一个容易被忽视的细节：Odoo附件权限有时候并不仅仅看当前模型字段的访问权限，还要看附件记录关联的模型和记录的权限。比如某订单的附件，即使你拥有“附件”菜单的访问权，但如果对订单本身没有读权限，系统也不会把附件预览入口暴露给你。这种二级联动权限在配置自定义安全规则时要特别留意，出现过不止一次“测试员有附件权限但看不到文件”的困惑。

4.2 网关与反向代理的推荐配置

如果部署在正式环境，强烈建议在Document Server前加一层Nginx反向代理，并启用HTTPS。原因不复杂，文档内容往往是业务核心数据，明文HTTP传输在公网环境里跟裸奔差不多。

反向代理配置里需要注意几个点：

• 代理时的Host头要保留，Document Server会根据Host生成回调地址和资源链接，改了Host容易导致页面加载资源404。
• WebSocket协议要转发。ONLYOFFICE在协同编辑时使用WebSocket做实时同步，如果Nginx只配置了普通HTTP代理，多人同时编辑时会发现保存卡顿、版本冲突。
• 超时时间不要设太短。文档编辑场景请求不是“秒开网页”那种短连接，笨办法是把proxy_read_timeout和proxy_send_timeout调到120秒以上。

一段基于常见实践的Nginx片段参考：

location / { proxy_pass http://127.0.0.1:8008; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 120s; proxy_send_timeout 120s; }

4.3 文件下载地址的暴露风险

ONLYOFFICE集成有一个经典安全讨论：Document Server在拉取文件时，Odoo会生成一个临时下载链接给它，这个链接如果有效期太长，理论上可以被拿到链接的人直接下载文件。

官方集成模块对这个问题的处理方式是：临时链接绑定有效期，并在生成后很快过期。文档编辑会话的生命周期通常也不会超过几个小时，所以实际风险可控。但自研集成时要特别注意，不要图省事生成永久链接，否则等于给业务系统开了一个无鉴权下载后门。

另外，Document Server在拉取文件时是服务端到服务端的访问，这个过程中如果再经过自建的文件代理，一定要确保代理不会把文件缓存在公开目录里。安全审计里最常见的“低危问题”就是这么来的。

5. 常见问题与排查技巧实录

5.1 打开附件白屏或持续加载

这个现象排在踩坑榜第一名，而且原因五花八门。我梳理下来的排查顺序是：

先看浏览器控制台是否有跨域（CORS）报错。Odoo前端页面和Document Server不在同一个域名下，站点之间的资源加载会触发CORS，Document Server需要允许Odoo域名的跨域请求。官方模块一般会自动处理，但如果你们改了Odoo域名或代理了Document Server的入口，跨域配置就可能失效。

再看Document Server的健康检查接口。确认服务本身活着，而不是假死。

最后确认Odoo配置的Document Server地址和用户浏览器实际访问的地址一致。如果Odoo用的内网IP，用户在外网访问，浏览器到不了内网IP，自然白屏。

5.2 编辑后保存按钮置灰或保存失败

保存失败首先要区分是权限问题还是通信问题。

权限问题的特征是“保存按钮压根点不动”，这通常是Odoo端给Document Server发送的编辑器配置里，权限标识为只读。检查当前用户在Odoo里是否有该附件对应记录的写权限，包括记录所属模型和附件字段本身的写属性。

通信问题的特征是“点保存按钮报网络错误”，这就回到第3节说的回调链路。在Document Server容器内手动curl一下Odoo的回调地址，看是否可达、是否返回预期JSON结构。

这里我提供一个基于实践经验的排查动作：直接翻Document Server的日志文件。它通常记录了进入编辑器的每次请求状态，包括文件拉取和回调保存。日志的报错信息比前端提示精准得多，能少走很多弯路。

5.3 多人同时编辑时文件锁定或版本冲突

ONLYOFFICE的协同编辑本身是支持多人同时操作的，但如果你发现打开文件时提示“文件已被锁定”，先检查Odoo模块的文件锁机制。Odoo文档附件默认不提供“正在被某人编辑”这种状态指示，集成模块可能会通过记录锁字段或协同标记来实现互斥。

如果想要多人真正协同，需要确保：

• Document Server配置启用了协同编辑模式，也就是不是“强制单用户”模式。
• Odoo模块版本不要过于陈旧。早期版本的集成模块在多人协同上的处理比较弱。
• 文件格式必须是ONLYOFFICE完整支持的格式。某些历史格式兼容性不够，ONLYOFFICE会自动退化为只读模式，看起来就像不支持协同。

5.4 文档中文字体显示异常或中文乱码

这个坑主要出现在Document Server容器缺少中文字体的环境里。Debian系的容器默认不带中文字体，导致打开的文档里中文全部变成方块或者乱码。

解决方案很简单，在容器里安装中文字体即可。基于常见实践的参考做法：

docker exec -it onlyoffice-document-server bash apt-get update apt-get install -y fonts-noto-cjk fonts-noto-cjk-extra

装完字体后重启容器，中文显示恢复正常。这个坑很隐蔽，初次接触ONLYOFFICE的人很难想到是字体问题，总以为是编码问题，折腾半天。

5.5 Odoo附件频繁出现“无法预览此文件类型”

这个提示出现的前提往往是文件扩展名和真实格式不匹配。比如一个实际上是DOCX的文件被命名成PDF后缀，Odoo模块按扩展名判断为不可预览类型，直接放弃加载ONLYOFFICE。

处理办法是两步：一是从源头规范附件上传时的格式校验，确保业务方不会乱改扩展名；二是对历史数据做一次格式探测清洗，把真实类型和扩展名修正过来。这个在日常运维里不算高频操作，但每次碰到都挺折腾。

5.6 大文件预览卡顿

Document Server处理大文件时，内存占用和CPU占用都比较可观。50MB以上的PPTX在普通配置服务器上会出现明显的加载延迟。

优化思路有三个方向：

• 上传环节限制单文件大小。Odoo本身没有做硬性限制，可以通过自定义约束把超过阈值的附件拦截下来。
• 部署时给Document Server独立规划资源，至少4G内存起步，多人并发场景8G以上更稳。
• 开启Document Server的缓存与预热机制。ONLYOFFICE支持配置缓存路径和缓存生命周期，合理设置后同一文件多次预览会快很多。

6. 性能调优与落地心得

6.1 Document Server的资源占用模型

ONLYOFFICE Document Server不是一个“轻量服务”，它内部起了一堆子进程，包括转换服务、编辑器服务、协同服务等。并发预览时CPU峰值会比较高，但这属于正常现象。我在实际运维中看到的现象是：单机2核4G配置下，支持日常几十人以内的预览基本够用，超过100人同时在线编辑就会明显吃力。

有条件的话，Document Server机器上配备SSD而不是机械盘。文件转换、临时文件读写都是高频IO操作，磁盘性能直接影响体验。这个建议听起来像废话，但就是有很多人在机械盘上部署，然后反馈“预览好慢”。

6.2 日志轮转与磁盘空间管理

Document Server运行久了，日志文件会膨胀得很快。默认的日志配置如果不做处理，半年就能吃掉几十GB磁盘空间。常见做法是宿主机层面加日志轮转，或者定期手动清理。

在Docker部署方式下，我习惯挂载日志目录到宿主机，然后在宿主机配置logrotate。举个例子：对挂载的/data/onlyoffice/logs目录做每日轮转，保留7天，压缩旧日志，这个策略能有效防止磁盘被日志打满。

磁盘满了的典型症状是：Document Server健康检查持续报错，但服务没宕，表现为操作卡死、文件拉取失败。所以磁盘监控的告警阈值要提前设好。

6.3 HTTPS证书与域名规划

生产环境尽量用HTTPS域名，而不是裸IP加端口。一方面浏览器对未加密HTTP的限制越来越多，另一方面存在多浏览器兼容问题。

域名规划上，考虑这样一个设计：内部人员走内网域名，外部协作者走公网域名。Document Server服务可以把两种入口都配好，但回调地址要和Odoo保持一致，否则文档保存时会出现回调源不匹配问题。这个细节在跨国团队协作场景下尤其重要。

6.4 备份与容灾视角

Odoo这边的附件数据本身就是数据库和文件存储的一部分，常规备份策略已经覆盖了。Document Server侧需要额外注意的是：它有自己的数据库和服务状态，但严格意义上不算是核心数据持有者，真正的文件在Odoo那边。因此备份策略可以简化——Document Server重启后能重新从Odoo拉取文件，它的容器数据主要是缓存和临时文件，丢了不至于丢失业务数据。

但有一个例外：如果你在Document Server上做了自定义模板、品牌定制、字体扩展或者插件，那这部分自定义配置需要纳入备份范围。否则换机器时，又要重新折腾一遍环境配置。

6.5 二次开发的几个方向参考

很多人在完成基础集成后会想： “能不能把ONLYOFFICE嵌入到Odoo的自定义页面上？” “能不能在审批流里触发文档的版本对比？” “能不能根据业务类型自动限制某些文档只能预览？”

这些都是合理的需求方向。基于已经跑通的架构来扩展，思路是：

• 自定义页面嵌入ONLYOFFICE。直接在前端页面加载ONLYOFFICE的JS SDK，把Odoo文件下载地址和Document Server地址配置好，再自己处理回调更新附件。
• 审批流版本对比。利用Document Server的文档历史版本能力，结合Odoo的追踪字段，在业务表单上显示“历史版本预览”入口。
• 业务类型限制。在模块代码里增加扩展钩子，根据模型记录的相关字段值决定生成的编辑器配置是只读还是可写。

不过要提醒一句：二次开发的关键不是技术难点，而是把权限边界重新想清楚。每一条新的文档打开路径，都需要走一遍“当前用户是否有权访问该附件”的校验逻辑。我见过太多开发者在二次开发时把权限校验做漏了，导致任意用户能通过构造URL预览任意文档，这是严重的越权漏洞。

7. 一些实际操作后的体会

这套方案我在几个环境里跑了一年多，总体的结论是：ONLYOFFICE和Odoo的集成，是当前开源ERP生态里落地文档在线办公最省心的一条路，没有之一。它不像某些商业化方案动不动要授权费，也不像某些简易预览方案那样只能看不能动。

有几个小建议分享给后来人：

部署时一定要先小规模试跑，确保预览、编辑、保存、版本记录全链路通掉，再对业务方全面开放。不要一上来就把所有附件都接管，可以先挑一两个高频格式试用。我在第一次部署时就犯过这个错误，直接全开，结果遇到几个老文件的格式不兼容，业务方马上就打退堂鼓。

日志一定要留好。Document Server的日志虽然噪点多，但排查问题时它几乎是唯一的权威参考。每次配置变更前，先看一眼当前日志基线，变更出问题能快速回滚对比。

最后提一下社区资源。Odoo和ONLYOFFICE都有自己的官方文档和论坛，遇到奇怪报错优先在这两个地方搜，比百度到处翻答案高效得多。版本升级前一定要看官方更新日志，特别是涉及JWT、回调路由、前端API这些底层组件的变更，升级后大概率需要同步更新Odoo侧模块版本。我踩过一次升级后版本不匹配导致的编辑器加载失败，原因就是两边版本跨度太大，配置格式已经不兼容了。

如果只是从零开始搭一套能够在线预览和编辑Office文件的Odoo环境，照着这篇文章的顺序来，大概半天时间就能跑通。真正需要花时间的，是在权限模型和业务场景的对接上想清楚。文档在线编辑这件事，技术方案本身不难，难的是让它在复杂的业务权限和组织架构里不越界、不泄漏、不卡壳。而这套ONLYOFFICE加Odoo的架构，起码让这个目标变得清晰了很多。