第一章 使用开发者模式快速入门 Odoo 15

Odoo提供了一个快速应用开发框架，尤其适合构建商业应用。这类应用通常用于保存业务记录和工作流。Odoo 不仅简化了这类应用的构建，还提供了看板、日历、图表等视图的丰富组件，用于创建难以抗拒的用户界面。

本章我们直接进入实操，通过web 界面进行编码一探Odoo 的内部，这甚至都不需要配置本地开发环境。这样会让我们直观地感受 Odoo 应用所涉及到的组件。同时，我们还会了解一些查看已有应用及快速构建原型的基本工具。

本文主要内容有：

• to-do (任务清单)应用
• 掌握 Odoo 的基础结构
• 使用 Odoo SaaS 测试库
• 在服务器上安装 Odoo
• 激活开发者模式
• 对模型添加自定义字段
• 新建模型
• 创建菜单项及动作
• 配置访问控制权限
• 创建视图

学习完本章，读者会熟悉 Odoo 自定义和开发的主要组成部分。

技术准备

学习本章至少要求有一个现代浏览器，如 Firefox 或 Chrome。有浏览器并且可以联网，就可以通过 Odoo SaaS测试库学习本章，无需进行本地安装。

当然读者也可以使用本地安装的 Odoo 实例。可以参见在服务器上安装 Odoo一节，其中讲解了 Windows、Ubuntu 和红帽企业版 Linux(RHEL)上安装预打包版本。此外，还可以使用 Docker 安装。

引入 to-do 清单应用

本章中我们会使用一个示例项目来演示所讲解的概念。这个项目就是一个简单的 to-do清单 Odoo应用。

使用这个应用我们可以新增清单，然后标记完成。比如可在项目中添加买鸡蛋，然后在购买后勾选已完成。并且To-do 清单应仅对用户自己可见，因而当前用户仅能获取自己的 to-do 列表。为了增加点趣味性，我们添加了一些复杂功能，允许 to-do清单包含一组和任务相关的用户，即工作小组。

就该应用我们应考虑以下几层：

• 数据层：通过模型实现
• 业务逻辑层：通过 Pyhon自动化编码实现
• 展示层：通过视图实现

对于数据层，我们需要一个 To-do 清单模型，我们还将利用内置的 Contact(也称之为 Partner)模型来支持工作组的功能。当然还要记得在新的模型中配置访问权限。

业务逻辑层中我们使用框架处理增删改查(CRUD)基本操作。本例中我们无需使用额外的自动化支持。我们需要在开发者模块中使用 Python 代码来使用自动化功能。我们暂不需要在开发的模板中使用，但可以在 Technical 菜单下的 Automated Actions 工具来通过 UI 界面实现这种业务逻辑。在本章后面的例子中会进行使用。

最后在展示层中我们将为应用添加菜单项，以及 to-do 模型的视图。业务应用的基本视图是用于查看已有记录的列表视图、深入查看记录详情的表单视图。为增强易用性，我们还可以在列表视图的搜索框中预置过滤项。搜索选项通过搜索视图组件进行实现。

以下是创建 to-do 列表应用的步骤

1. 新建 to-do 清单模型
2. 创建菜单项并让其对用户可见
3. 配置访问控制权限
4. 为 to-do 清单创建列表和表单视图

新增的 to-do 清单模型包含如下字段

• • Description: 字符 类型
  • Is Done?标记：布尔型

应用的具体功能包含团队功能：即可添加执行同一任务的一组用户。因此需要一个表示用户的模型。Odoo 自带就有Contact模型( 技术名称为res.partner)，可用于存储个人、公司和地址。

任务清单模型应当包含一个工作团队字段，可用于选择一组用户。我们希望仅有指定的人可被选择加入工作团队。因此我们需要修改 Contact 模型添加Is Work Team?标记。仅带有此标记的用户可添加至工作团队。

为实现工作团队的功能，我们需要向Contact 模型和表单视图添加一个字段。在进入实施之前，我们先讨论一些与 Odoo 框架相关的功能，然后学习如何准备要使用的环境。

理解 Odoo 的基本概念

对一初学 Odoo 的人可能有些概念不是那么一目了然。我们在学习之前先进行掌握。

有关 Odoo 和 Odoo 社区

Odoo 是一个是 Fabien 在比利时所创建的Odoo SA 公司所发布的软件产品。Odoo 软件产品是由公司主导的，也就是说路线图及开发都由 Odoo SA 紧紧控制在手里。但同时又遵循开源的条例，欢迎社区贡献代码。

Odoo 软件采取开源内核的商业模式，也就是说部分代码是开源的、部分是自有产权。基于这一模式，Odoo 发布了两个版本。

社区版（CE）对外公开、开源，使用 LGPL 开源证书。

企业版（EE）仅对官方合作伙伴及持有专有证书的顾客开放，采取闭源代码。

Odoo EE是 Odoo CE 内核上层的一堆模块，提供一些可诱使用户升级的高级功能。Odoo EE的收入为Odoo CE及Odoo EE的开发提供资金来源。Odoo创始人及 CEO Fabien Pinckaers 反复承诺会将80%的代码放到社区版里开源，另20%放到自有的企业版中。

任何开源项目的最大资源都是围绕其的社区。Odoo 有很多活跃的开源贡献者。对于 Odoo 这个产品，社区贡献了功能反馈、翻译、安全问题报告、bug 修复并且偶尔会对内核产品进行一些技术改进。Odoo CE 的地址为https://github.com/odoo/odoo。

除了 Odoo 的内核产品外，社区还发布一些新功能模块。很多 Odoo 社区内的个人及公司将他们的 Git 仓库以开源证书向公众开放。他们也会在 Odoo 的官方商店 Odoo Apps 上发布应用。应用商店中可发布免费及付费模块。

Odoo 的内核项目中不会添加这些社区模块，因此社区模块以分散的形式开发，没有共同的标准及品控。Odoo 社区联盟（OCA）的成立就是为了解决这一问题。它纳入了这些社区贡献的模块，并提供了通用代码标准、指南、品控及工作流工具。OCA 的代码仓库位于https://github.com/OCA，可以在https://odoo-community.org/shop查看这些发布的模块。

Odoo 产品的版本

在编写本书时，Odoo 的最新稳定版是 Odoo 15，在 GitHub 上的分支为15.0。这是在全书中使用的版本。Odoo 的大版本按年发布，每年10月在 Odoo 体验大会上进行发布。

官方支持最新的三个稳定版。发布版本15后，对13和14版本仍提供支持，但版本12就不再进行官方支持了。也就是说不再进行漏洞及安全问题修复了。

Odoo 的大版本之间数据库是不兼容的。如果在 Odoo 15的服务端运行此前大版本中创建的数据，不会跑通。要在更新的 Odoo 版本中使用老数据库需要进行颇为费力的迁移。

对于插件模块也是如此。通常在一个大版本中开发的 Odoo 插件在另一个大版本中无法运行。在网上下载社区模块时，请注意是否支持你所使用的 Odoo 版本。

大版本发布（如15.0）通常会有比较频繁的升级，这大部分都是漏洞修复而非新功能的开发。这些升级确保 API 稳定，即模型数据结构和视图元素标识符保持稳定。这很重要，因为这样就不会因为上游内核模块做出不兼容修改而导致自定义模块崩溃。

Odoo 在线 SaaS 版本可能会使用中间版，有时也称为 SaaS 版。它们也是官方支持的。当前支持的版本列表可见于https://www.odoo.com/documentation/user，在 Support 页面的 Practical Information 中。

master 分支的版本会形成下一个大版本的更新，但在发布前其 API 并不稳定，不应使用它构建自定义模块。那会好比在流沙中前行，无法知道何时会出现导致自定义模块崩溃的修改。请收下这个警告。

Odoo 的架构

了解Odoo 遵循多层架构以及我们使用的每种组件的角色会很有帮助。因此我们来学习下 Odoo 应用的架构并通过将其解构为多个组件层来帮助我们进行应用的开发。

Odoo 应用可以解构为三层：数据层、逻辑层和展示层:

图1.1：Odoo 应用分层

数据层是最底端一层，负责数据存储和持久化，Odoo 借助 PostgreSQL服务端来实现。Odoo 出于设计考虑仅支持 PostgreSQL 数据库。文档附件、图片一类的二进制文件通常存储在一个称为 filestore（目录） 的文件系统中。

小贴士：也就是说 Odoo 实例的完整备份需包含数据库导出文件和 filestore 的拷贝。

我们很少使用 SQL 直接与数据库引擎进行交互 ，但在特定场景可能会需要用到。

Odoo 依赖于对象关系映射（ORM）作为应用和数据库之间的接口。ORM 提供插件模块与数据交互的应用程序接口（API）。我们使用ORM模型实现数据层。例如，用于客户或供应商数据的Partner数据实体，以模型进行表示。

通常底层数据库应仅由这一层访问，因为它确保了安全权限控制和数据一致性。ORM 模型基于支持多个交互方法的Python对象类，如增删改查（CRUD）基本操作。具体来说CRUD操作通过create()、search()、write()和unlink()模型方法实现。

逻辑层负责与数据层的所有交互，并由 Odoo 服务端处理。可扩展CRUD操作来实现具体的业务逻辑。例如，create() 和 write() 方法可实现默认值或其它的自动操作。可添加其它方法来强制验证规则或自动计算字段值。

展示层用于展示数据并与用户交互，通过软件的客户端实现，负责用户交互。客户端软件使用远程过程调用（RPC）运行 ORM 引擎及业务逻辑的Odoo 服务。ORM API调用发往Odoo服务端处理读、写、验证或执行其它操作。然后将结果返回客户端做进一步处理。

Odoo自带一个网页客户端。网页客户端支持所有业务应用所需的功能，如登录会话、导航菜单、数据列表和表单。

有一个网站框架用于外部的开发前台。它提供一些 CMS 功能，可用于创建静态和动态网页。网站框架使用controller组件来实现具体展示逻辑的代码，与模型内部逻辑分离。页面使用QWeb作为其渲染引擎。那是一些包含HTML标记外加循环、条件或调用其它模板的特有XML QWeb标签。

Odoo 服务端 API 非常开放，包含所有的服务端功能。官方Web 客户端使用的 API 与其它应用的 API 并无不同。因此，其它的客户端实现均可做到，并且可以在任何平台上使用任意编程语言进行实现。可以创建桌面和移动端应用来提供不同用户界面，这充分利用了 Odoo 为业务逻辑和数据持久性而生的数据和逻辑层。

使用 Odoo SaaS试用数据库

使用Odoo最简单的方式是使用Odoo的软件即服务(SaaS)试用数据库。这样无需进行任何安装，仅需进入官网https://odoo.com/点击Try it free按钮。

会要求选择一个应用来在新数据库中进行安装。在本章的学习中，你可以选择任何应用，读者大可自由选择。如果你实在拿不定主意，不妨使用CRM应用。

图1.2 – Odoo SaaS试用数据库的初始应用选取

新的SaaS数据库使用最新的Odoo SaaS版本，它是基于最近的稳定版Odoo EE，同时带有自己的小版本号。因此与Odoo最新稳定的企业版版本号并不致。

免费数据库有效期为15天。在写本书时，Odoo SaaS版本还提供一个免费方案让你可以在到期后继续使用（要求安装一个以上的应用）。

在工作站上安装 Odoo

使用Odoo SaaS测试库是本章的默认选项。在本书之后的章节中，我们会使用本地Odoo安装。在第二章 Odoo 15开发之开发环境准备中，会进行相应的引导。

值得一提的是Odoo还有一些预打包的安装包。我们这里简要地进行说明，以供读者了解：

• 在你的操作系统上使用预打包安装程序安装Odoo：如果是Odoo新手又希望快速获得一个本地环境的话这是一个很好的选择。预打包安装软件支持如下操作系统：Windows (EXE安装软件); Debian/Ubuntu (DEB包)和CentOS/RHEL (RPM包)。
• 使用 Docker 容器安装 Odoo：如果用过 Docker 并在操作系统中安装了 Docker 这会是一个好选项。如果不太了解 Docker，可以采用上一种方法，以名学习 Docker影响到正课（学习 Odoo 开发）。

可通过https://download.odoo.com下载这些安装包。包含所有稳定版的Odoo，以及与最新开发版本相对应的 master 分支。我们会在下面的小节讲解这些选项。

有关安装Odoo的更多知识，请参见官方文档。

使用一键安装包在 Windows 上安装

Odoo为Windows提供了一个一键安装包，包含运行Odoo所需的所有：Python 3运行时环境、PostgreSQL数据库以及安装了依赖的Odoo服务端。

可通过https://download.odoo.com下载安装包。在首页选择相应的版本：15 (stable) – Community Edition。每日构建包位于15.0/nightly/windows，最新包在页面底部。

安装包非常易于使用。在安装结束时Odoo会自动启动。

还会创建开机启动的Windows服务用于自动启动Odoo和PostgreSQL。在通过其它如源码方式安装时应注意这一点，在Windows安装包安装后会占用8069端口，这样其它安装就无法使用该端口了。

使用预打包安装包在 Linux 上安装

Odoo下载站点(https://download.odoo.com) 还提供对Debian系(含Ubuntu)和RHEL/CentOS的官方包下载仓库。

在首页上对于有对应系统安装包(apt 或 yum) 的安装指南。请确保将命令行示例中的Odoo版本修改为对应的版本，如15.0。

在Linux系统中安装Odoo 15之前，应当先安装好PostgreSQL数据库。这样Odoo就可以创建并配置其用户了。

使用 Docker 容器安装 Odoo

Docker为在运行应用提供了一个便利的多平台解决方案。可用于在Windows、Linux和macOS上运行应用。相比于传统的虚拟机容器技术使用简单、资源利用率高。

首先需要在操作系统中安装Docker。Docker Desktop是社区版的，免费使用。可通过https://www.docker.com进行下载。安装最新版本 Docker时最好参照该网站。Docker依赖于虚拟硬件技术，请确保在基本输出输出系统 (BIOS)中启用该功能。

有关安装和运行Docker的通用指南请见https://docs.docker.com/engine/install。

例如对于Ubuntu系统，详细地的安装说明位于https://docs.docker.com/engine/install/ubuntu/。

关于安装后的重要步骤，如以非root用户运行Docker，请参见https://docs.docker.com/engine/install/linux-postinstall/。

Windows系统中的Docker桌面需要使用Hyper-V，仅在Windows 10的企业版和教育版中才有。最新安装详情请见https://docs.docker.com/desktop/windows/install/。

Mac上的Docker桌面需要使用macOS 10.14或更新版本。最新的详情请见https://docs.docker.com/desktop/mac/install/。

Odoo 在Docker Hub上的官方Docker镜像位于https://hub.docker.com/_/odoo。这里我们可以看到使用Odoo Docker镜像的基本指南。运行Odoo时会创建两个Docker容器：一个用于PostgreSQL数据库，另一个用于Odoo服务端。

安装及操作均通过命令行实现。通过如下命令启动PostgreSQL的Docker容器：

这样会通过互联网下载最新的PostgreSQL镜像并启动一个以后台任务运行的容器。

接着，安装、运行Odoo服务端容器，联结刚刚启动的PostgreSQL容器，对外暴露端口8069：

此时便可在终端窗口看到实时的 Odoo 服务器日志，在浏览器中访问http://localhost:8069即可打开 Odoo 实例。

以下Docker 的几个基本命令会有助于管理容器：

• docker stop <name>：停止容器
• docker start <name>：启动容器
• docker start -a <name>：启动容器并附带输出，如在命令终端中输出的服务器日志
• docker attach <name>：重新添加容器输出至当前终端窗口
• docker ps：列出当前 Docker 容器

以上就是操作 Docker 容器的基本命令。

万一在运行容器时出现问题，可以执行如下命令重新来过：

Docker 技术的应用非常广泛，学习起来也很有趣。Docker官网上有不错的文档可供学习，可先通过https://www.docker.com/get-started开始学习。

启用开发者工具

要实现我们的项目，这里需要用到Odoo开发者工具。通过开启开发者模式即可使用这些工具。

开发者模式对于查看和修改当前Odoo的配置很有用。可直接通过用户界面自定义Odoo应用并快速添加、修改功能。可用它做些小修改，比如创建带有自己菜单、视图及底层数据模型的应用。

这种通过开发者工具的自定义开发相对于在后续章节讲到的编程工具而言存在其局限性。如它无法添加或扩展默认的 ORM 方法。

借助于开者模式（通过Odoo Studio应用）的自定义开发不易于集成到结构性开发流，如版本控制、自动化测试及质量测试、预发布和生产环境改进的工作流。

本文我们主要使用开发者模式来介绍在 Odoo 框架中应用配置数据是如何进行组织的，以及如何在开发者模式下完成简单的自定义或原型解决方案。

开启开发者模式

从Odoo 13开始，通过Settings > General Settings页面开启开发者模式。在接近底部的地方会发现一个Developer Tools的版块。在这里可以找到Activate the developer mode链接。点击该链接就会在当前浏览器窗口中开启开发者模式功能：

图1.3 – Settings页面中的开发者工具选项

注意需要至少安装了一个应用后才会出现General Settings菜单。如果找不到该菜单，请安装一个应用，如Contacts或CRM等任一应用。

启用了开发者模式后，会出现如下的菜单：

• 菜单栏中，右上角聊天和活动图标左侧会新增一个开发者工具的小虫子图标。
• 在Settings应用中，顶栏中会出现Technical和Translations菜单项。

图1.4 – 开启了开发者模式后的设置页面

开启开发者模式后在网页视图上会出现一些额外信息，即在将鼠标悬停在字段上，会有一个提示框显示相关的技术信息。

使用带资源的开发者模式

为了加载更快，网页客户端对JavaScript和CSS资源进行了最小化压缩。这会给调试带来困难。

Activate the developer mode (with assets)选项会阻止这种最小化压缩，让每个资源单独加载。对于在网页客户端中进行调试这很有用处，但也会因开销开让页面的浏览变慢。

说说 Odoo Studio

值得一提的是Odoo企业版和SaaS版都提供了Odoo Studio应用，这是一个交互的应用构造器。我们不会使用到它，因为本书的示例均使用 Odoo 社区版，社区版中没有这一功能。

Odoo Studio提供了一套用户友好的界面，用于完成本章中讲解的交互式开发功能及一些其它功能，比如可以将自定义功能导出到文件中。

这里我们会使用开发者模式（有时也被称为debug模型）及Technical菜单，这两者在Odoo所有的版本中都可用。Odoo Studio中所构建的大部分功能通过这两个工具也可完成，不过对于非开发者来说确实也难些。

对模型添加自定义字段

向已有表单添加自定义字段是一种很觉的自定义，无需创建自定义模块通过用户界面就可实现。

我们的to-do清单应用中，希望选择一组人共同操作to-do清单项。可以在他们的partner表单设置一个标记来进行指定。我们将通过向Contact模型添加一个Is Work Team?标记来实现。

Contact模型是Odoo内核自带的，即使未安装任何应用也可以使用。但这样就没有菜单选项来访问它了。

如果在主菜单中没有Contacts应用的话，请进行安装。打开顶级菜单的Apps项，搜索该应用进行安装。

图1.5 – Apps菜单中添加Contacts应用

安装完成后即可在顶级菜单中找到 Contacts 项。

对模型添加字段

我们先在数据模型中添加自定义字段。

点击Contacts应用菜单项查看联系人主视图。点击开发者工具小虫图标并选择View Fields选项。

ODOO 12中的变化

开发者菜单中的View Fields选项是在Odoo 12中新增的，可通过Settings >Technical >Database Structure菜单添加、编辑字段。可以使用Models或Fields选项。

此时会看到当前模型Contact所有已有字段的列表。点击左上角的Create按钮、填入新字段的以下详情：

• Field Name: x_is_work_team
• Field Label: Is Work Team?
• Field Type: boolean

图1.6 – 创建Is Work Team?字段

字段名（Field Name）必须以 x_开头。这是通过开发者工具创建模型和字段强制要求的（否则保存时会提示Custom fields must have a name that starts with ‘x_’ !）。通过插件模块的自定义开发没有这一限制。

点击Save，就会在字段列表中新增这个字段。默认，列表视图显示80条记录，因此需要点击右上角的右键浏览下一页查看新字段，或者也可以编辑箭头旁的记录数。

对表单视图添加字段

现在Contact模型中就有一个新字段（前面也提到过也称为Partner模型）。但在用户界面中仍不可见。需要为其给定一个视图。我们会添加一个联系人表单视图。

回到Contacts的列表并打开表单视图，可通过选择已有的联系人或点击Create按钮。

现在需要决定在表单的哪里添加这个字段。例如，我们应在Tags标签后进行添加。这会是使用的扩展点。

将鼠标悬浮在字段上，会显示其技术信息，如下图所示：

图1.7 – 带有技术详情提示信息的Tags字段

接下，我们需要找到该字段的技术名称。可通过将鼠标悬停在字段标签之上。这样我们可以看到该字段的名称为category_id。

现在可以扩展表单视图添加字段。点击开发者工具小虫图标，选取Edit View: Form选项。这会打开表单定义的容器。

图1.8 – 表单视图编辑窗口

在Architecture标签页下，可以看到基础视图的XML。可以直接进行编辑，但这不是个好做法，因为在模块升级时修改会丢失。正确的方式是通过创建一个扩展视图来对其编辑。

安装额外的模型可以对基础视图添加更多的字段及视觉元素。这是通过使用扩展视图完成的，并且可在Inherited Views标签页下查看。我们会在这里为联系人表单视图添加我们的扩展。

在Inherited Views列表中，点击底部的Add a line ，使用如下的值创建扩展视图：

• View Name: 添加一些短描述，如Contacts Form extensions for To-do App。
• Architecture: 这会要求一个指定扩展点及所添加内容的XML片断。使用<field name="category_id" position="after"><field name="x_is_work_team"/></field>。

扩展视图应当像下图这样：

图1.9 – 创建扩展视图来添加x_is_work_team字段

现在点击Save & Close，如果所填XML没有错误，会加到Inherited Views列表，其中会包含我们添加的扩展。点击Save按钮完成对表单视图的修改，通过点击右上角的x关闭Edit Form: View窗口。

修改已完成，但需要重新加载表单才能看到修改。重新加载页面，现在Tags字段下面应该会出Is Work Team?字段，如下图所示：

图1.10 – 带有Is Work Team? 字段的联系人表单视图

这样就完成了在表单视图中添加自定义字段的步骤。表单只是这些视图类型中的一种。下一节中详细讨论视图的类型。

了解视图类型

我们刚刚操作了一种视图类型，表单视图。但用户界面中还使用了其它的视图类型。

Contacts的初始视图类型为看板视图，以数据卡片显示一些字段。看视图还可以按列组织卡片。例如，CRM应用以这种初始视图形式显示，称为管道视图。在看板视图中，开发者菜单中显示Edit View: Kanban选项。

列表视图（有时也称为树状视图）以列表显示记录。在列表视图中，开发者菜单会显示Edit View: List选项。

最后，搜索视图控制看板视图及列表视图右上角搜索框的行为，以及其下的按钮：Filters和Group By。在搜索框可见时，开发者菜单会显示一个Edit View: ControlPanelView选项。

视图类型并不仅限于这些，还有其它的类型，我们会在第十章 Odoo 15开发之后台视图 – 设计用户界面中进行探讨。

可通过Settings > Technical > User Interface > Views菜单项查看所有的视图定义。

一种更详细的方式是使用Settings > Technical > Database Structure > Models来所要的模型（本例为res.partner，也称之为Contact），并打开Views标签。

图1.11 – Contact模型的数据库结构

这里，我们可以看到所选模型的所有视图定义。可以通过View Type列看到不同类型视图的记录，以及基础视图及它们的扩展。修改或新增视图记录会即刻生效，在下次重新加载视图时即可看到修改。

按视图类型排序有助于查看同一视图类型的所有扩展。

基础视图是Inherited View字段，有些为空。视图类型并不仅限于一种基础视图。例如，Contact模型(res.partner)的表单视图有多个基础视图，如base.view_partner_form和base.view_partner_simple_form。

视图还有一个Sequence字段。Sequence序号最小的基础视图为默认显示的视图。在查看表单视图定义时，会看到这个Sequence值。窗口动作用于菜单项，可指定具体使用的基础视图。我们提到，如果未定义某个视图，会使用序号最小的那个。

新建模型

模型是构建应用的基本组件，包含了所需使用到的数据结构和存储。接下来我们就为 To-do 清单应用添加模型，有三个字段：

• Description文本
• Is done? 标记
• Work team（即在清单中相互协作的用户列表）

模型名应使用单数形式，因此新模型的名称应为To-do Item。模型技术名称必须为有效的数据库对象标识符，因此我们应使用字母和下划线，避免使用其它符号。因为通过Technical菜单创建的模型必须带有x_前缀，这个新模型的技术名称使用x_todo_item。

通过菜单Settings > Technical > Database Structure > Models进入模型定义页面。

点击Models列表中的Create按钮创建新模型：

1. 填入基本定义值：在Model Description字段中输入To-do Item，Model字段输入x_todo_item。
2. 默认，模型会在字段列表中包含x_name字段。这是在列表中显示记录或在其它记录引用它时显示的标题。可用作To-do Item的标题，因此编辑修改相应的Field Label列（改为 Title）。
3. 接下来添加Is Done?字段。这应当很明确。在Fields列表中，点击底部的Add a line打开新的视图表单，输入如下值：
   1. Field Name: x_is_done
   2. Field Label: Is Done?
   3. Field Type: boolean

   然后点击Save & Close按钮，再点击模型表单中的Save。
   
   图1.12 – 新建字段表单

4. 接下来的Work Team字段应该会更有挑战性了。不仅是因为这是一个引用Contact (res.partner)模型中记录的关联字段，而且它还是一个多值选择字段。
   所幸的是Odoo支持多对多关联。本例正是如此，因为每条任务清单可关联多个联系人，而每个联系人又可关联多条任务清单。
   在Fields列表中添加Work Team字段，需要再次点击表单的Edit按钮，接着点击Add a line打开新增字段表单。然后输入如下值：
   1. Field Name: x_work_team_ids
   2. Field Label: Work Team
   3. Field Type: many2many
   4. Related Model: res.partner
   5. Domain: [(‘x_is_work_team’, ‘=’, True)]

   多对多字段有一些专有的基础属性：Relation Table, Column 1和Column 2。这些会自动进行填写，通常使用默认值即可。在第六章 Odoo 15开发之模型 – 结构化应用数据中会详细讨论到这些属性。
   Domain属性是可选的，它为所展示的记录定义了一个过滤器。我们使用它来将联系人限定为勾选了Is Work Team?标记的人。否则会在选项中出现所有联系人。

   Domain 表达式遵循Odoo 独有的语法 – 一个包含三个值的可迭代对象，每个对象是一个过滤条件，表示待过滤的字段名、过滤运算符及过滤所使用的值。详细的解释参见第七章 Odoo 15开发之记录集 – 使用模型数据。

   小贴士：Odoo有一个交互式的 domain 过滤向导可帮助生成作用域表达式。访问Settings > Technical > User Interface > User-defined Filters菜单。在表单中选中目标模型后，Domain字段会显示一个+ Add filter按钮用于添加过滤条件。下面的文本框会动态地显示作用域表达式代码。

5. 在完成后，点击模型表单的Save。创建好新模型后，会自动添加一些字段。ORM引擎在所有模型中添加了它们，在进行审计时会很有帮助：
   
   图1.13 – To-do清单模型的数据库结构
   现在to-do列表应用的底层模型就绪了，但用户还是无法访问。为此，需要配置访问权限。在下一节中我们进行学习。

创建菜单项和动作

现在已经有了存储任务清单的模型，我们希望在用户界面中添加它。可在UI中添加菜单项实现。

我们会创建一个直接打开任务列表的顶级菜单。一些应用（如Contacts）正是这样，而另一些则是顶栏下的子菜单。

菜单的定义位于Settings应用的Technical > User Interface > Menu Items 中：

图1.14 – Technical菜单中的Menu Items选项

我们执行如下步骤创建菜单项：

1. 进行上图的页面，点击Create，输入如下值：
   1. Menu: To-do
   2. Parent Menu: 留空
   3. Action: 选择 ir.actions.act_window
   4. 在Action字段旁的选择框中输入To-do Items, 在下拉列表中选择Create and Edit…，这时会打开Create: Action 表单弹窗。
2. 在Create: Action表单中，设置如下值：
   1. 1. Action Name: To-do Items
      2. External ID Object: x_todo_item (目标模型的技术名称)。
      3. 此时，动作定义应该是下面这样：

   图1.15 – Create: Action表单

3. 点击Create: Action 表单中的Save。然后在Menu Items表单中点击Save，然后to-do列表应用的菜单项就差不多可以使用了。

菜单的修改要求对整个页面重新加载才可以看到。大多数浏览器可通过F5快捷键来重新加载。但如果现在刷新页面的话，是看不到To-do菜单的。为什么呢？我们现在还看不到菜单的原因是还没有给用户授权访问。

在对用户展示菜单项之前需要配置访问权限。我们在本章中会进行处理，但在那之前，有必要更深入地讨论一下窗口动作。

了解窗口动作

本例中，对不带有子菜单项的顶级菜单项直接添加了一个动作。但菜单可以是包含父子关系的树状菜单项。枝叶菜单项拥有一个关联动作，定义选中后的行为。动作名就是在展示视图中使用的标题。

有好多种动作类型，最重要的有窗口、报表和服务端动作。窗口（window）动作是最常用到的，用于在客户端中展示视图。报表（report）动作用于运行报表，而服务端（server）动作用于定义自动化任务

这里我们关注的是用于显示视图的窗口动作。刚刚创建的to-do清单菜单项使用了一个直接通过Menu Item表单创建的窗口动作。我们也可以通过Settings > Technical > Actions菜单项查看、编辑这个窗口动作。本例中我们感兴趣的是窗口动作菜单选项。

小贴士：很多情况下，使用开发者工具菜单中的Edit Action选项会更为方案，它提供了编辑当前视图窗口动作的快捷方式。

配置访问控制权限

Odoo自带有权限控制机制，用户仅能使用已授权的功能。这就意味着我们创建的任务清单模型用户是访问不到的。。

Odoo 12中的变化
admin用户现在也像其它用户一样受权限控制所限制。在此前的 Odoo 版本中，admin 都作为特权用户不受权限规则控制。这一情况发生了变化，admin必须要获得授权才能访问模型数据。

访问权限通过用户组定义。组有时也称为访问控制列表(ACL)，定义访问模型的权限。用户隶属于组。因此，每个用户的权限依赖于其所属组。

对这个项目，我们会创建一个to-do组，将其分配给访问该项功能的用户。

此外，我们还可以定义记录规则（有时称作行级权限），用于限制每个用户可访问哪些记录。

本项目中 to-do 项为每个用户私有，所以用户仅能访问自己创建的记录。

安全组

访问控制基于组。通过安全组对模型设置权限，控制组内用户所能使用的菜单项。要做更精细化的控制，我们可以通过记录规则对指定菜单项、视图、字段甚至是数据记录进行权限控制，在下一小节中会进行讲解。

安全组还可以对应用进行管理，通常每个应用有两个组：用户组(User)可执行日常操作、管理员组(Manager)可对应用执行所有配置。

下面我们为to-do清单应用新建一个安全组。

在Settings顶级菜单中，导航至Users & Companies > Groups，使用如下值新建一条记录：

• Application: 留空
• Name: To-do User
• Inherited 标签下: 添加一行，选择User types / Internal User

效果如下：

图1.16 – To-Do User安全组

我们的安全组继承了 Internal User组。组的继承表示该组的成员也是所继承组的成员，并对所有的用户累加授权的权限。Internal User 是基础权限组，通常应用的安全组都继承它。

在 Application 下拉列表中还没有to-do 应用，所以我们直接通过组表单来添加。我们还，那么这个组的成员也会自动（递归）成为所继承组的成员，以获取他们原有的权限。

Odoo 12中的变化
在 Odoo 12之前，Internal User组称作雇员(Employee)，这只是表面上的修改，代码中标识符(XML id)仍然和此前版本相同：base.group_user。

安全访问控制列表

现在我们可以将组To-do User授权给指定模型了。

最简单的方式是使用Groups表单中的Access Rights标签。使用如下值添加一行：

• Name: To-do Item User Access
• Object: 在列表中选择To-do Item
• 勾选Read Access, Write Access, Create Access和Delete Access：勾选所有这些复选框来授予对应的权限。

模型权限也可通过Settings > Technical > Security > Access Rights菜单进行管理。

我们无需单独向 Contact 模型添加权限，因为我们的组继承了Internal User组，已经获取了相应权限。

对用户分配安全组

现在可以将 admin 用户添加到新建权限组来测试新增的权限设置：

1. 在菜单中点击Users & Companies > Users，打开Mitchell Admin用户的表单，点击Edit。
2. 在Access Rights标签下的 Other 版块，会发现一个名为 To-do User 的复选框用于将用户加入权限组。勾选后点击 Save 保存表单。

图1.17 – Mitchel Admin用户表单

如果一切操作都正确的话，我们就可以看到 To-do 应用顶级菜单。应该需要重新加载浏览器页面强制刷新菜单项。

我们还没有为其创建任何视图，但优秀的Odoo框架自动为我们生成一些基本视图：

安全记录规则

在对模型赋予访问权限时，默认用户可以访问到它的所有记录。但有时我们要限制每个用户所能访问的记录。通过记录规则可以实现这一点。

记录规则通过对模型定义 domain 过滤器来对读和写操作进行控制。

比如我们这里的 to-do 清单应用，任务项应为每个用户私有的，我们不希望其他用户看到自己的记录。需要添加记录规则来过滤出创建者自己的记录，考虑如下几点：

• 框架会自动添加create_uid字段，并存储创建记录的用户。因此可使用它来知道每条记录的创建者。
• 域运行上下文包含一个user变量，其中含有当前用户的浏览器记录。因此我们可以使用点号运算符访问其属性，如user.id的值。

我们可在作用域表达式中使用如下来实现目标：

[('create_uid', '=', user.id)]

通过菜单中的Settings > Technical > Security > Record Rules 或开发者菜单的View Record Rules选项进入记录规则设置页。进行页面后使用如下值新建记录规则：

• Name: 一个描述性的标题，如 To-do Own Items
• Model: 在下拉列表中选择模型，此处为To-do Item
• Access Rights: 规则所授予的操作，这里保留全部勾选
• Rule Definition (Domain Filter): 填写 [(‘create_uid’, ‘=’, user.id)]
• Groups: 这部分包含所应用的安全组。点击Add a line 、选择To-do User组

此时记录规则的定义如下：

图1.19 – To-do User Own Items记录规则

此时就完成了记录规则的设定。现在可以试试用 Admin 和 Demo 用户（需提前将 Demo 用户加入到安全组）分别创建几个任务项。各自应该只能看到自己创建的任务了。

了解超级用户账号

Odoo包含一个内置的像root那样的超级用户，它拥有特殊权限、可不受权限控制的限制。它用于那些需忽略权限控制的内部操作或动作。这个超级用户名为OdooBot，在数据库创建时自动创建，在数据库中的ID为1。

Odoo 12中的变化

在Odoo 12之前。用于系统配置的默认admin用户也是超级用户。因此，admin用户默认不受权限控制。在Odoo 12中进行了调整。现在，默认的admin用户是一个普通用户，但默认它被设为所有Odoo应用的管理员。

超级用户没有登录密码，但可以激活该账号。在通过Admin \ Setting组用户登录时，开发者菜单中会有一个Become Superuser选项。

也可以直接在登录界面进行超级用户模式。这时需要通过修改URL添加?debug=1来开启开发者模式（如http://localhost:8069/web/login?debug=1）。然后中在Login按钮下方就会出现Login as superuser选项。

在启用了超级用户后，右上角的当前用户显示为 OdooBot，该区域会变成黄黑相间的条状，以清晰地告知用户开启了超级用户。

注意：

仅在绝对必要时才应使用超级用户。超级用户不受权限控制这点会导致数据的不一致性，比如在多公司场景下，所以应尽量避免。

创建视图

我们创建了To-do Item模型，并且通过菜单项可在用户界面中访问到它。下面我们为其创建两个基本的视图：列表视图和表单视图。

列表视图中用户浏览已有记录的最基本方式。有时，可在列表视图中直接编辑记录，但更常见的是点击记录访问表单视图来编辑记录数据。

创建列表视图

我们可在Settings > Technical > User Interface > Views中管理视图。在该页面点击Create按钮，输入如下值：

• View Name: To-do List View
• View Type: Tree
• Model: x_todo_item
• Architecture：这个标签应包含视图结构的XML。使用如下XML代码：
  
  <tree> <field name="x_name" /> <field name="x_is_done" /> </tree>

  1 2 3 4

  <tree>   <field name="x_name" />   <field name="x_is_done" /> </tree>

这时视图的定义如下所示：

图1.20 – 任务清单列表视图定义

列表视图的基本结构相当简单，它包含一个<tree>元素，内部含有一个或多个对应视图中所显示字段的<field>元素。

在列表视图中还可以做其它有趣的操作，我们会在第十章 Odoo 15开发之后台视图 – 设计用户界面中进行更详细的探讨。

创建表单视图

表单视图也可以通过Settings > Technical > User Interface > Views创建。通过点击Create创建另一条视图记录，填入如下值：

• View Name: To-do Form View
• View Type: Form
• Model: x_todo_item
• Architecture：在该标签内，输入如下XML 代码:
  
  <form> <group> <field name="x_name" /> <field name="x_is_done" /> <field name="x_work_team_ids" widget="many2many_tags" context="{'default_x_is_work_team': True}" /> </group> </form>

  1 2 3 4 5 6 7 8 9

  <form>   <group>     <field name="x_name" />     <field name="x_is_done" />     <field name="x_work_team_ids"           widget="many2many_tags"           context="{'default_x_is_work_team': True}" />   </group> </form>

注：如果不指定 View Type,将会通过视图定义代码来自动识别。

表单视图结构根节点为<form>元素，包含<field>等元素。其它相关元素将在第十章 Odoo 15开发之后台视图 – 设计用户界面中进行学习。对x_work_team_ids工作组字段，我们使用了一个指定的微件many2many_tags，它会以按扭行标签的形式代替普通列表显示关联记录。

还可以看到在x_work_team_ids工作组字段中使用了一个context属性。默认，关联字段允许我们直接新建关联中使用的记录。因此，用户可以通过Work Team字段直接新建Partner记录。因为只有标记为Is Work Team?的联系可供选择，我们希望默认创建的联系人都启用该标记。这就是default_x_is_work_team上下文键干的事，为通过该字段创建的记录设置默认值。

这样我们就新建好了表单视图。如果现在使用To-Do 菜单项新建清单任务或打开列表中已有的记录，会看到刚刚所添加的表单视图。

创建搜索视图

我们可以在Odoo的视图界面左上角中看到一个搜索框。搜索框让我们可以在指定的字段中进行搜索。在搜索框下面有Filters和Group By 按钮，提供了一些预定义选项。

搜索视图是一种控制这些行为的UI元素。它定义了在搜索框中输入时所做的搜索以及Filters和Group By按钮内的选项。

视图可以通过Settings > Technical > User Interface菜单或Odoo 13起开发者菜单的Edit ControlPanelView选项进行编辑，更早的版本中使用Edit Search View。

当前任务清单模型还未定义过搜索视图，所以我们应当新建一个。我们为过滤菜单添加一个选项来过滤出未完成的清单。

在新增View表单中填入如下值并点击Save：

1. View Name: To-do Search View
2. View Type: Search
3.  Model: x_todo_item
4.  Architecture: 在该标签下添加如下XML 代码:
   
   <search> <filter name="item_not_done" string="Not Done" domain="[('x_is_done', '=', False)]" /> </search>

   1 2 3 4 5

   <search>   <filter name="item_not_done"     string="Not Done"     domain="[('x_is_done', '=', False)]" /> </search>

此后，重新打开或加载任务清单视图时，在Filters的选项列表中就会出现Not Done选项。

对视图启用默认过滤器

默认就开启这个过滤器会比较好，在不需要时删除。

在点击To-do菜单项时，它运行一个窗口动作打开To-do列表视图。窗口动作的context对象可用于设置默认过滤器，类似于对字段设置默认值。

我们使用如下步骤：

1. 打开To-do菜单进入任务清单列表视图
2. 打开开发者工具菜单并选择Edit Action。这时将弹出一个用于打开当前视图的窗口动作表单。在General Settings标签栏的Filters版块中，有一个Context Value和Domain Value字段。
3. 在Context Value字段中，输入{‘search_default_item_not_done’: True}

search_default_前缀指示默认选取一个具体的过滤器，这里为item_not_done。现在如果点击To-do菜单项，会看到在搜索框中默认启用了Not Done，并且用户可以自由取消选择。

Domain Value字段也可用户对显示的记录设置过滤器，但设置的过滤器用户无法移除。

小结

在本章中，我们不仅总览了 Odoo 的组件，还利用开发者模式深入到 Odoo 内部来理解这些组件如何共同协作创建应用。

我们还使用这些工具创建了一个简易的应用，包含模型、视图和对应的菜单。并且学习了如何通过开发者工具查看已有应用或在用户界面中直接进行快速自定义操作。

下一章中我们将学习如何通过源码安装Odoo，以及准备Odoo模块开发所使用的开发环境。

喜欢 (24)赏

[]

分享 (0)