洛阳泰山的博客

在Odoo中，小部件（Widgets）是用于构建用户界面的组件，它们决定了表单、列表视图以及更多交互元素的显示和行为方式。虽然无法提供Odoo14及之后所有版本的确切小部件清单，但可以列举一些常见和重要的内置小部件类型：field - 基础字段小部件，用于显示和编辑各种类型的字段数据。form表单显示为tree视图里显示为selection - 下拉选择列表。使用方法：form表单显示为普通下拉框，tree视图里显示为普通文本selection_badge - 下拉徽章选择列表。

在Odoo中，动作（Actions）是系统的核心组件之一，负责定义系统响应用户交互的具体行为。动作定义了系统对用户操作的响应行为，例如登录、按钮点击、发票选择等。动作可以存储在数据库中或直接作为字典在按钮方法中返回。typename。

指令只能被放置在模板文件的顶级（作为文档根元素的直接子元素）：t-name

本页介绍Odoo编码指南。这些旨在改善 Odoo应用程序代码的质量。事实上，适当的代码可以提高可读性，简化 维护，帮助调试，降低复杂性并提高可靠性。 这些准则应适用于每个新模块和所有新开发。警告在稳定版本中修改现有文件时，原始文件样式 严格取代任何其他风格准则。换句话说，请不要永远 修改现有文件以应用这些准则。它避免了中断 代码行的修订历史记录。差异应保持最小。查看更多 有关详细信息，请参阅我们的拉取请求指南。警告在主（开发）版本中修改现有文件时，应用这些 仅针对已修改代码的现有代码的指南，或者如果文件的大

Odoo遵循多层架构，这意味着演示，业务逻辑和数据存储是分开的。更具体地说，它使用三层架构 （图片来自维基百科）：表示层是和的组合。逻辑层是专门用编写的，而数据层只支持作为。根据模块的范围，可以在这些层中的任何一层进行开发。因此，在进一步学习之前，如果你对这些主题没有中级水平，那么刷新一下你的记忆可能是个好主意。为了完成本教程，您将需要非常基本的知识和中级水平的。高级主题将需要更多其他科目的知识。有很多免费的教程，所以我们不能推荐一个而不是另一个，因为这取决于你的背景。作为参考，这是官方的。

到目前为止，我们的房地产模块的界面设计还相当有限。构建列表视图很简单，因为只需要字段列表。表单视图也是如此：尽管使用了几个标签，如 标签或 标签 ，但在设计方面几乎没什么可做的。然而，如果我们想为我们的应用程序提供独特的外观，就必须更进一步，能够设计新的视图。此外，其他功能，如PDF报告或网站页面，需要另一种工具来创建，以提供更大的灵活性：模板引擎。你可能已经熟悉了现有的引擎，如 Jinja（Python）、ERB（Ruby） 或 Twig（PHP）。Odoo 自带其内置引

在前一章中，我们使用继承来修改模块的行为。在我们的房地产场景中，我们希望更进一步，能够为我们的客户生成发票。Odoo提供了一个发票（Invoicing）模块，所以直接从我们的房地产模块创建一个发票会很简洁，也就是说，一旦一个属性被设置为“已售出”，发票就会在发票应用程序中被创建。

向模型添加字段，覆盖模型中字段的定义，向模型添加约束，向模型添加方法，重写模型中的现有方法。

从商业角度来看，我们的房地产模块现在是有意义的。我们创建了特定的视图，添加了几个操作按钮和约束。然而，我们的用户界面仍然有点粗糙。我们想为列表视图添加一些颜色，并使一些字段和按钮有条件地消失。例如，当属性被出售或取消时，’‘和’'按钮应该消失，因为此时不再允许更改状态。这一章涵盖了视图能做的事情中的很小一部分。如有需要，请阅读参考文档以获得更完整的概述。

前一章介绍了向模型添加一些业务逻辑的能力。现在我们可以将按钮链接到业务代码，但是我们如何防止用户输入错误的数据呢?例如，在我们的房地产模块中，没有什么可以阻止用户设置负预期价格。Odoo提供了两种方法来设置自动验证的不变量:Python约束和SQL约束。

到目前为止，我们主要通过声明字段和视图来构建我们的模块。在上一章中，我们刚刚通过计算字段和onchanges引入了业务逻辑。在任何真实的业务场景中，我们都会希望将一些业务逻辑链接到操作按钮。在我们的房地产示例中，我们希望能够：取消或设置已售出属性接受或拒绝报价有人可能会说，我们可以通过手动更改状态来做这些事情，但这并不方便。此外，我们想添加一些额外的处理：当接受要约时，我们想设置房产的销售价格和买方。

模型之间的关系是任何Odoo模块的关键组成部分。它们是任何业务案例建模所必需的。然而，我们可能希望给定模型中的字段之间存在链接。有时一个字段的值是由其他字段的值决定的，而有时我们希望帮助用户进行数据输入。这些案例得到了计算字段和onchanges概念的支持。虽然本章在技术上并不复杂，但这两个概念的语义非常重要。这也是我们第一次编写Python逻辑。到目前为止，除了类定义和字段声明之外，我们还没有编写任何内容。

上一章介绍了自定义的创建 包含基本字段的模型的视图。但是，在任何实际业务场景中，我们需要的不仅仅是 一个模型。此外，模型之间的链接是必要的。人们可以很容易地想象一个模型包含 客户和另一个包含用户列表的客户。您可能需要推荐客户 或任何现有商业模式的用户。在我们的房地产模块中，我们需要房产的以下信息：购买房产的客户出售房产的真正重述经纪人物业类型：洋房、公寓、顶层公寓、城堡…该物业的特征标签列表：舒适，翻新…收到的报价列表。

我们在上一章中已经看到Odoo能够为给定模型生成默认视图。在实践中，默认视图是绝对不可接受的用于商业应用程序。相反，我们至少应该以逻辑方式组织各种字段。在带有和的XML文件中定义。它们是ir.ui.view模型的实例。在我们的房地产模块中，我们需要以合乎逻辑的方式组织字段：在tree 列表（树）视图中，我们希望显示的不仅仅是名称。在form表单视图中，应对字段进行分组。在search 搜索视图中，我们必须能够搜索的不仅仅是名称。具体来说，我们想要一个 过滤“可用”属性和按邮政编码分组的快捷方式。

现在我们已经创建了我们的新模型及其 相应的访问权限，是时候了 与用户界面交互。在本章结束时，我们将创建几个菜单以访问默认列表 和窗体视图。

在上一章中，我们创建了第一个表 用于存储业务数据。在像Odoo这样的业务应用程序中，第一个问题 要考虑的是谁1 可以访问数据。Odoo提供了一种安全机制来允许访问 添加到特定用户组的数据。限制对数据的访问中更详细地介绍了安全性主题。本章旨在 以涵盖我们新模块所需的最低要求。

在上一章的最后，我们能够创建一个Odoo模块。然而，在这一点上，它仍然是一个空壳，不允许我们这样做 存储任何数据。在我们的房地产模块中，我们希望存储与 数据库中的属性（名称、描述、价格、居住面积等）。Odoo框架提供 促进数据库交互的工具。在继续练习之前，请确保已安装estate房地产模块，即 必须在“应用”列表中显示为“已安装”。(点击启动即可)

本章的目的是为创建一个全新的Odoo模块奠定基础。我们将从头开始，以使我们的模块被Odoo识别所需的最低限度。在接下来的章节中，我们将逐步添加功能以构建一个真实的业务案例。

Odoo是一套全球开源的ERP/CRM系统，最初的名字为TinyERP，08年5月之后称之为OpenERP，之后又改为Odoo。

开始odoo17开发之前，请先掌握python的基本语法和工具包的使用，以及postgres数据库的安装，和简单的sql使用。以及一些前端的html、css、javascript等前端知识，以及xml、json等数据传输的使用。