从 Odoo 17 迁移到 Odoo 18：哪些变化、哪些中断以及如何准备

Odoo 每年都会发布一个主要版本，每次升级都会带来新功能、性能改进，并且不可避免地会带来重大变化。从 Odoo 17 迁移到 Odoo 18 需要仔细规划，特别是如果您运行自定义模块或依赖社区附加组件。本指南涵盖了您需要了解的有关 Odoo 17 到 18 迁移的所有信息：关键更改、潜在损坏、准备步骤和测试策略。

为什么升级到 Odoo 18？

Odoo 18 在整个平台上引入了重大改进：

• 新的 OWL 3 组件： 重写了前端组件，提高了性能和开发人员体验
• 人工智能驱动的功能： 预测线索评分、智能银行对账建议和人工智能辅助内容创建
• 电子表格改进： 本机电子表格与实时 Odoo 数据、数据透视表和协作编辑集成
• 制造升级： 改进生产调度、分包门户和车间平板电脑界面
• 性能： 通过优化的资源捆绑和延迟加载，页面加载速度提高 15-25%
• 网站构建器： 新的拖放块、主题自定义选项和改进的移动编辑

继续使用过时的版本意味着缺少安全补丁、无法访问社区模块更新以及积累技术债务，从而使未来的迁移变得更加困难。

时间表：Odoo 迁移需要多长时间？

|复杂性 |定制模块|预计时间表 | |---|---|---| |标准（无自定义代码）| 0 | 1-2 周 | |低（很少自定义字段/视图）| 1-5 | 1-5 2-4 周 | |中（自定义工作流程）| 5-15 | 5-15 4-8 周 | |高（深度定制）| 15+ | 8-16 周 |

这些时间表包括分析、迁移、测试和上线。最大的变量是自定义模块的复杂性。

Odoo 18 中的重大变化

OWL 框架变更

Odoo 18 继续迁移到 OWL 3。如果您的自定义模块包含前端 JavaScript 组件，则预计会发生以下变化：

关键 OWL 更改：

• 组件生命周期： willStart 和 willUpdateProps 替换为 setup() 和 onWillStart 钩子
• 模板编译： QWeb 模板现在在构建时而不是运行时编译为优化的 JavaScript
• **服务注入：**仅通过this.env.services模式访问服务；不推荐直接导入
• 资产捆绑： web.assets_backend 捆绑结构已更改；更新您的 __manifest__.py 资产声明

迁移示例：

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

Python 后端更改

模型和字段更改：

• fields.Monetary 现在需要显式声明 currency_field （不再默认为 currency_id）
• @api.multi 装饰器已完全删除（自 v13 起已弃用，但一些社区模块仍在使用它）
• sudo() 行为更改：不带参数的 sudo() 现在显式使用 SUPERUSER 而不是 OdooBOT 用户
• search_count() 现在接受可选的 limit 参数以优化性能

不推荐使用的更新方法：

|已弃用 (v17) |替换 (v18) | |---|---| | 代码0 | fields.Many2one 与 domain 属性 | | 代码0 |清单中的 _post_init_hook | |模型中的直接 SQL |具有正确参数化的 self.env.cr.execute() | | website.published 字段 | website.is_published（重命名）|

视图和模板更改

• 表单视图： sheet 包装器现在对于所有表单视图都是必需的（以前是可选的）
• 列表视图： tree 标记正式重命名为 list （向后兼容的别名仍然有效，但会触发弃用警告）
• 看板视图： QWeb t-esc 现在是默认值； t-raw 需要明确选择加入以确保安全
• 报告 QWeb： PDF 渲染引擎更新；测试所有打印报告的布局更改

数据库架构更改

Odoo 18 包括对核心表的结构更改：

• sale.order.line 获得订阅管理的新字段
• account.move.line 包括新的调节相关列
• stock.quant 表进行了重组，以提高大库存的性能
• 使用新索引优化 mail.message 和 mail.activity 表

这些架构更改由 Odoo 的标准模块内置迁移脚本处理，但引用这些表的自定义模块需要手动更新。

迁移前准备清单

1. 审核您当前的安装

在开始之前记录一切：

• [ ] 列出所有已安装的模块（官方、社区和自定义）
• [ ] 记录当前 Odoo 版本和补丁级别
• [ ] 记录所有自定义开发（字段、模型、视图、报告、计划操作）
• [ ] 列出所有外部集成（支付网关、运输公司、第三方 API）
• [ ] 导出当前访问权限并记录规则配置
• [ ] 完整备份生产数据库和文件存储

2.检查社区模块兼容性

对于每个社区（OCA 或第三方）模块：

• 检查 GitHub 或 Odoo 应用商店中是否存在 Odoo 18 兼容版本
• 如果不存在兼容版本，请决定是否自行移植模块、寻找替代方案或删除该功能
• 联系模块维护人员以获取 v18 端口上的 ETA

3. 准备自定义模块端口

对于每个自定义模块，评估迁移工作：

省力（每个模块 1-3 天）：

• 仅具有新字段和简单视图的模块
• 没有 JavaScript/OWL 组件
• 不会覆盖已更改的核心方法

中等工作量（每个模块 3-10 天）：

• 带有需要更新的 OWL 组件的模块
• 覆盖已弃用或更改的核心方法
• 需要 QWeb 更新的自定义报告

高强度（每个模块 10 天以上）：

• 与变更后的核心模块（会计、库存、网站）深度集成
• 复杂的OWL前端应用程序
• 广泛使用已弃用或删除的 API 的模块

与经验丰富的 Odoo 迁移专家 合作可显着减少移植自定义模块的时间和风险。

迁移执行步骤

第 1 步：设置迁移环境

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

创建一个隔离的环境：

• 全新的 Odoo 18 服务器安装
• 您的生产数据库的副本
• 所有自定义模块移植到 v18

步骤 2：运行数据库升级

对于 Odoo Enterprise： 使用 Odoo 的官方升级服务：upgrade.odoo.com。上传您的数据库，Odoo SA 会运行所有标准模块的迁移脚本。

对于 Odoo 社区： 使用 OCA 的 openupgrade 项目。 OpenUpgrade 为标准模块提供社区维护的迁移脚本：

1.安装目标版本的OpenUpgrade 2. 针对测试数据库运行迁移 3. 查看迁移日志中的错误和警告 4. 修复任何问题并重新运行直至干净

步骤 3：移植自定义模块

对于每个自定义模块：

1.更新__manifest__.py版本为18.0.x.x.x 2.修复Python代码（已弃用的API、更改的方法签名） 3. 将 JavaScript/OWL 组件更新为 v3 模式 4. 修复 XML 视图（树形列表、表单包装、模板更改） 5. 运行模块的测试套件并修复故障 6.在登台环境中手动测试

第四步：数据验证

迁移后，验证数据完整性：

• 会计： 比较 v17 和 v18 之间的试算表总计。它们必须完全匹配。
• 库存： 验证高价值产品样品的库存数量。
• 销售/采购： 确认未结订单及其状态是否正确结转。
• 联系人： 检查客户和供应商记录是否完​​好，包括地址和银行详细信息。
• 附件： 验证文档、图像和文件附件是否可访问。

测试策略

1 级：自动化测试

为每个已安装的模块运行完整的测试套件。在继续之前修复所有故障。

第 2 级：功能测试

端到端测试核心业务工作流程：

• 创建报价、确认、交付货物、创建发票、登记付款
• 通过收据和供应商账单处理采购订单
• 运行从 BOM 到成品的制造订单
• 完成完整的银行对账周期
• 生成并验证关键财务报告

第 3 级：用户验收测试 (UAT)

让每个部门的实际用户在临时环境中执行 5-10 个工作日的日常任务。在共享电子表格或项目管理工具中跟踪问题。

第 4 级：性能测试

将 v17 和 v18 之间的页面加载时间、报告生成速度和搜索性能与生产级数据量进行比较。

上线策略

推荐方法：周末迁移

1. 周五晚上： 进行最终的生产备份。冻结所有交易。
2. 星期六： 在生产数据库上运行升级。移植所有最后一刻的数据。
3. 周日： 完成数据验证和冒烟测试。部署到生产服务器。
4. 周一早上： 上线。前 48 小时内密切监测。

准备好回滚计划：保持 v17 数据库备份和服务器配置可用，以便在出现严重问题时可以在数小时内恢复。

常见问题

问：我可以跳过版本并直接从 Odoo 16 迁移到 Odoo 18 吗？ 是的，但它更复杂。每个版本都有自己的迁移脚本，跳过版本会加剧更改。 Odoo 的升级服务可以处理多版本跳转，但自定义模块移植需要解决每个跳过版本的重大更改。为多版本迁移节省 50-100% 的时间。

问：我的自定义报告会在迁移过程中中断吗？ 有潜力。由于更新的数据结构和渲染引擎的改进，QWeb 报告模板在版本之间经常发生变化。迁移后测试每个打印的报告（发票、交货单、采购订单）并根据需要调整模板。

问：我应该迁移还是重新开始？ 如果您拥有多年的历史数据、复杂的配置和经过培训的用户，请迁移。如果您当前的安装经过大量定制而无法修复，存在严重的数据质量问题，或者您的业务流程发生了很大变化，重新配置会更快，请重新开始。大多数企业选择迁移来保留其运营历史。请咨询 Odoo 咨询合作伙伴 以评估哪种方法适合您的情况。

专业的迁移支持

Odoo 版本之间的迁移是一个技术项目，需要经验丰富的人员的帮助。 ECOSIRE 的 Odoo 迁移服务 涵盖整个流程：迁移前审核、自定义模块移植、数据迁移、测试和上线支持。

联系我们的团队，根据您的具体 Odoo 安装进行迁移评估和时间表估算。我们将分析您的模块、定制和数据复杂性，以提供准确的范围和预算。