前言

Odoo 的前世今生

Odoo 的前身可追溯至比利时开发者 Fabien Pinckaers 在上世纪九十年代起步的 TinyERP：面向中小企业的开源 ERP，强调「一体化业务软件」——财务、进销存、客户关系等尽量在同一套系统中完成，而不是多套孤岛系统反复对账。

随着产品规模与社区扩大，项目曾以 OpenERP 之名在国际上推广；这一阶段形成了延续至今的核心思想：模块化架构（每个业务域以独立模块扩展）、Python 业务层 + PostgreSQL 数据层，以及通过 XML/后续演进机制声明 模型、视图、权限与数据。

约 2014 年 品牌正式更名为 Odoo，寓意跳出「仅 ERP」的刻板印象，向更广泛的 企业应用平台 发展。与此同时，商业模式逐步清晰为 开源社区版（Community）+ 商业企业版（Enterprise） 的「开放核心（open-core）」路线：核心框架与大量标准模块保持开源可审计，部分高级应用、官方托管服务（如 Odoo.sh）与增值服务构成商业闭环。无论名称如何变化，同一套技术栈与扩展机制始终是开发者投入回报最高的主线。

各版本脉络：区别何在、技术如何革新

下面按「时代」概括主流版本差异与技术演进，便于读者建立时间坐标；具体 API 以当前所用版本的官方文档为准。

1. 早期与新旧 API 交替（约 7.x–9.x）

  • 客户端：以传统 Web 界面为主，交互与今天相比更偏「页面刷新式」。
  • 服务端：曾广泛使用旧式 osv/orm 风格；自 8.0 起引入 @api 新 API（models.Model、recordset、@api.depends 等），并经历较长的 新旧并存、逐步迁移 阶段。
  • 意义：新 API 奠定了现代 Odoo 开发的表达习惯——记录集、环境与装饰器，也是今天阅读老代码时仍会遇到「迁移痕迹」的来源。

2. Python 3 与现代化后端（约 11.x–14.x）

  • 11.0 起官方主线全面转向 Python 3，弃用 Python 2，带来字符串、编码与依赖生态的整体升级。
  • ORM、权限、多公司、网站（Website） 等能力持续增强；标准应用在 销售、采购、库存、会计、网站 等方向更加完整。
  • 意义：开发与部署环境与现代 Python 生态对齐，为后续前端大改版与性能优化打下基础。

3. OWL 前端与资产体系（约 15.x–17.x）

  • 前端逐步从旧式 JavaScript 架构过渡到 OWL（Odoo Web Library）组件模型，视图与字段控件已逐步 组件化、可注册（registry）。
  • 静态资源以 bundles / assets 方式组织，强调按需加载与可维护性。
  • 意义：扩展界面不再主要依赖「魔改全局对象」，而是更接近现代前端工程：组件 + 服务 + 注册表。

4. 持续清理与平台化（约 18.x–19.x）

  • ORM 与 RPC 继续 废弃陈旧入口、统一环境访问方式（例如全面使用 record.env 而非历史遗留的分散属性），并引入更易用的 外部 API（如 JSON-2 一类新接口，以官方文档为准）。
  • 安全与权限 API 趋向统一（如更一致的访问校验与过滤手段）。
  • AI、电子表格（Spreadsheet）、文档抽取（Extract） 等与业务数据结合更紧，体现「业务平台 + 智能化」方向。
  • 意义：开发者需要同时关注 后端契约稳定迁移 与 前端组件化扩展，并把 安全默认值 当作一等需求。

阅读本书的建议：书中以 Odoo 19 为叙述锚点；若你维护 16–18 的项目，请以官方 ORM Changelog 与 Release Notes 对照差异，避免把本书中的 19-only 写法直接套到旧库。

应用领域：Odoo 能做什么

Odoo 的定位是 可扩展的企业应用套件 + 开发平台，常见应用领域包括但不限于：

领域 说明
通用 ERP 财务、采购、销售、库存、制造、项目成本等一体化或分步实施。
CRM 与营销 线索、商机、活动、邮件营销与销售漏斗（常与销售、网站联动）。
电商与官网 Website、在线目录、购物车、支付与物流对接（视版本与模块而定）。
制造与供应链 MRP、质检、条码、多仓、补货规则等（企业版/行业模块往往更完整）。
服务与项目型业务 项目、工时表、服务合同、工单与现场服务（FSM）等场景。
人力资源 招聘、考勤、假期、薪酬相关扩展（区域合规常需本地化模块）。
垂直行业 医疗、教育、非营利、零售门店、农业等常通过 官方应用 + 社区/伙伴模块 组合落地。
集成与定制 作为 中台：对接电商平台、MES、银行、物流、BI；或用 Studio / 自定义模块 快速贴合流程。

开发者视角：无论上层应用如何组合，底层仍是 模型—视图—权限—自动化—报表—接口 同一套扩展模型；本书后续章节即围绕这条主线展开，帮助你在不同行业项目中 复用方法、控制复杂度、安全交付。

插图一：Odoo 应用矩阵（建议置于本节之后、印刷单页或跨栏）

下图占位对应文件：images/ch00-apps-matrix.png。用于直观呈现 「一套平台、多类应用」 的产品形态，与上表应用领域对照阅读。

图 0-1 Odoo 应用矩阵（后台「应用」界面，展示主要应用分类与图标）

拍摄内容建议

  • 使用 已安装较完整应用集 的数据库（演示库或内部沙箱），以 内部用户 登录 后台（Backend）。
  • 打开 应用（Apps） 主界面：以 网格状应用卡片 为主画面，尽量包含销售、采购、库存、会计、项目、网站、员工等 多列多行，避免大量空白。
  • 浏览器窗口宽度建议 1280px 或 1440px，缩放 100%，隐藏书签栏与无关插件，界面语言与全书一致（中文或英文）。
  • 可接受 轻微裁剪：去掉浏览器地址栏以下仅保留 Odoo 顶栏 + 应用区（印刷更干净）。

印刷与导出参数建议

成书版心 插图宽度（版心内） 导出像素（约 @300dpi） 备注
A4 单栏（版心约 120mm 宽） 满栏 110–118mm 短边 1300–1500 px 宽即可 常用学术/培训教材版式
A4 双栏 单栏 52–58mm 或 通栏 通栏时同左；单栏可 700–900 px 宽 通栏跨双栏时整幅更清晰
A5 单栏（版心约 95mm 宽） 88–92mm 1050–1200 px 宽 口袋书、讲义
  • 格式：交排版前优先 PNG（无压缩伪影）；若印厂要求 TIFF 或 CMYK PDF，由其从 PNG 转即可。
  • 分辨率：以印厂要求为准；上表按 300 dpi 粗算，勿低于 250 dpi 有效分辨率。
  • 出血：若整页满版印刷，外缘预留 3 mm 出血；插图若嵌入正文页、四周留白，通常 无需出血。
  • 色彩：屏幕截图为 RGB；商业印刷可能需印厂做 RGB→CMYK 转换，避免高饱和蓝/绿严重偏色。

插图二：版本与技术演进示意（可选，建议自绘矢量）

若希望前言更有「时间轴」可读性，可增加一页 矢量时间线（Indesign / Illustrator / draw.io 导出 PDF/SVG），占位文件建议：images/ch00-evolution-timeline.png（或由印厂直接使用 PDF）。

图 0-2 Odoo 版本与技术演进示意（时间轴：新旧 API → Python 3 → OWL → 平台化/AI）

绘制建议：横轴为年代/大版本号，纵轴或色块标注四段：7–9 新旧 API、11–14 Python 3 与后端、15–17 OWL 与 assets、18–19 清理与外部 API/AI；文字精简，与正文「各版本脉络」一节一致，避免过密。

本书与 Odoo 19

本书 章节目录与文件清单 以 全书索引 为准，侧重 可教学、可排版 的章节体例（案例、练习与截图占位）。API、视图 XML、CLI 参数与安全规则等权威细节 请以 Odoo 19.0 官方开发者文档 与 ORM Changelog 为最终依据。

与官方文档协同阅读：官方结构分为 Tutorials（教程）、How-to guides（操作指南）、Reference（参考手册） 三层。本书各章与上述板块的对应关系、精选 How-to 链接及 User Docs 周边入口，已整理为独立对照表，便于按需跳转：

祝你在 Odoo 的演进浪潮中，写出清晰、可维护、可升级的业务代码。

前言完。