Odoo 15开发手册第八章 业务逻辑 - 业务流程的支持

在前面的文章中，我们学习了如何使用模型层构建应用数据结构，然后使用ORM API 和记录集查看和操作这些数据。

本章中，我们把前面所学串到一起实现一些应用中常见的逻辑模式。我们会学习一起触发业务逻辑的方式，以及支撑这些方式的一些常见模式。我们还将学习一些重要的开发技巧，如打日志、调试和测试。

本章的主要内容有

• 学习项目-图书借阅模块
• 触发业务逻辑的方式
• 理解记录集的ORM方法装饰器
• 探讨一些数据模型模式
• 使用ORM内置方法
• 添加onchange用户界面逻辑
• 消息和活动功能
• 创建向导
• 抛出异常
• 编写单元测试
• 使用日志消息
• 学习一些开发工具

学完本章后，读者可以自如地设计、实现业务逻辑自动化以及了解如何测试、调试代码。

开发准备

本章中我们会创建一个library_checkout插件模块。它依赖于前面章节中所创建的library_app和library_member插件模块。

这些插件模块的代码请参见​​GitHub 仓库​​的ch08目录。

这些插件模块要放到Odoo的插件路径中，这样才能安装使用。

学习项目–图书借阅模块

图书应用的主数据结构已就绪。现在需要对系统添加交易了。让图书会员可借阅书籍。也即我们要跟踪图书是否可借阅以及是否归还。

每本书的借阅都有一个生命周期，从图书登记到图书被归还。这可通过看板视图表示为简单工作流，看板视图中每个阶段(stage)可展现为一列，工作项和借阅请求流从左侧列到右侧列，直至完成为止。

在本章中，我们集中学习实现这一功能的数据模型和业务逻辑。

用户界面部分的详情将在​​第十章 Odoo 15开发之后台视图 - 设计用户界面​​中讨论，看板视图在​​第十一章 Odoo 15开发之看板视图和用户端 QWeb​​中讨论。我们来快速过一遍数据模型吧。

准备数据模型

首先我们就规则图书借阅功能所需的数据模型。

图书借阅模型应包含如下字段：

• 借阅图书的会员（必填）
• 借阅请求日期（默认为当天）
• 负责借阅的用户（默认为当前用户）
• 借阅路线，包含请求借阅的一本或多本图书

要支撑借阅生命周期，需要添加如下内容：

• 请求的阶段：已选中、可借阅、已借出、已归还或已取消
• 待归还日期，图书应当归还的日期
• 归还，图书归还的日期

我们先新建library_checkout模块并实现图书借阅模型的初始版本。与此前章节相比此处并没有引入新的知识，用于提供一个基础供本章后续构建新功能。

创建模块

和前面章节一样，需要创建library_checkout模块。按照如下的步骤：

1. 在其它图书插件模块的同级路径下创建一个library_checkout目录。后续的文件都在这个目录中添加。
2. 在​​__manifest__.py​​文件中加入如下内容：

{
    'name': 'Library Book Borrowing',
    'description': 'Members can borrow books from the library.',
    'author': 'Alan Hou',
    'depends': ['library_member'],
    'data':[
        'security/ir.model.access.csv',
        'views/library_menu.xml',
        'views/checkout_view.xml',
    ],
}

1. 在模块目录下创建​​__init__.py​​文件，并添加如下代码：

from . import models

1. 创建​​models/__init__.py​​文件并添加：

from . import library_checkout

1. 添加模型定义文件​​models/library_checkout.py​​并加入如下代码：

from odoo import fields, models
class Checkout(models.Model):
    _name = "library.checkout"
    _description = "Checkout Request"
    member_id = fields.Many2one(
        "library.member",
        required=True,
    )
    user_id = fields.Many2one(
        "res.users",
        "Librarian",
        default=lambda s: s.env.user,
    )
    request_date = fields.Date(
        default=lambda s: fields.Date.today(),
    )

下面就要添加数据文件了，添加访问规则、菜单项和一些基础视图，这样模块就可以使用了。

1. 在security/ir.model.access.csv文件中添加访问权限配置：

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
checkout_user,Checkout User,model_library_checkout,library_app.library_group_user,1,1,1,1

1. 接下来添加views/library_menu.xml实现菜单项：

<odoo>
    <record id="action_library_checkout" model="ir.actions.act_window">
        <field name="name">Checkouts</field>
        <field name="res_model">library.checkout</field>
        <field name="view_mode">tree,form</field>
    </record>
    <menuitem id="menu_library_checkout"
              name="Checkout"
              action="action_library_checkout"
              parent="library_app.menu_library" />
</odoo>

1. 在views/checkout_view.xml文件中实现的视图：

<odoo>
    <record id="view_tree_checkout" model="ir.ui.view">
        <field name="name">Checkout Tree</field>
        <field name="model">library.checkout</field>
        <field name="arch" type="xml">
            <tree>
                <field name="request_date" />
                <field name="member_id" />
            </tree>
        </field>
    </record>
    <record id="view_form_checkout" model="ir.ui.view">
        <field name="name">Checkout Form</field>
        <field name="model">library.checkout</field>
        <field name="arch" type="xml">
            <form>
                <sheet>
                    <group>
                        <field name="member_id" />
                        <field name="request_date" />
                        <field name="user_id" />
                    </group>
                </sheet>
            </form>
        </field>
    </record>
</odoo>

既然模块已经包含以上这些文件了，就可以在开发数据库中进行安装了：

​​

​​

图8.1：初始图书借阅功能

下面我们可以开始添加更多有意思的功能了。

在整个项目的开发中，我们会不停地在不同处添加业务逻辑来展示Odoo所提供的那些功能。下一小节就会进行一部分讨论。

触发业务逻辑的方式

准备好数据模型后，就需要业务逻辑来执行一些自动化操作。业务逻辑可直接由用户发起，比如点击按钮，或根据事件自动触发，如在记录中写入。

这类业务逻辑大多涉及读取和写入记录节。详细的技巧在​​第七章 Odoo 15开发之记录集 - 使用模型数据​​中进行了讨论，在其中我们提供了实现实际业务逻辑的工具。

下一个问题是业务逻辑应怎样触发。这取决于何时以及为什么触发业务逻辑。下面进行了一部分总结。

部分业务逻辑与模型字段定义紧密关联。一些模型定义相关的业务逻辑实例如下：

• 数据验证规则：强制数据满足某些条件。这类方法使用@api.constrains装饰。
• 自动计算：以字段（虚拟或存储字段）进行实现，其值由方法计算。这类方法使用@api.depends装饰再赋值给compute字段属性。
• 默认值：可动态计算，这类方法使用@api.model装饰再赋值给default字段属性。

模型定义逻辑在​​第六章 Odoo 15开发之模型 - 结构化应用数据​​中进行了讨论。相关的例子可见数据模型模式一节。记录集的ORM方法装饰器一节提供对一些这里所说的ORM装饰器的回顾。

还有模型事件相关业务逻辑，与业务工作流相关。可与以下记录相关事件进行关联：

• 可对这些事件添加创建、写入、删除业务逻辑，而其它更优雅的方法则无法使用。
• 对用户界面视图可应用Onchange逻辑，这样一些字段的值可以在其它字段发生变化时做出改变。

对于直接由用户发起的动作，有以下选项：

• button视图元素用于调取对象方法。按钮可位于表单或列表的看板视图中。
• server动作可在菜单项或Action上下文菜单中使用。
• 用于打开向导表单的window动作，可由用户输入，按钮会调用业务逻辑。这使得用户交互更丰富。

这些技巧在本章都会用到。支持的方法通常使用API装饰器，因此理解它们的不同很重要。为了能拨云见雾，下一节中进行综述。

理解记录集的ORM方法装饰器

方法定义前可添加@，对方法进行装饰。这些装饰器对方法添加特定的行为，根据方法的作用不同，可使用不同的装饰器。

计算字段和验证方法装饰器

• @api.depends(fld1,...)用于计算字段函数，标记(重新)计算应触发什么样的修改。必须设置在计算字段值上，否则会报错。
• @api.constrains(fld1,...)用于模型验证函数并在任意参数中包含的字段修改时执行检查。不应在数据中写入修改，如检查失败，则抛出异常。

在​​第六章 Odoo 15开发之模型 - 结构化应用数据​​中进行过详细的讨论。

另一组装饰器影响self记录集的行为，与实现的业务逻辑相关。

影响self记录集的装饰器

默认方法应作为于由第一个参数self所提供的记录集。方法代码中通常包含for语句循环self记录集中的每条记录。

ODOO 14中的变化

Odoo 14中删除了@api.multi装饰器。此前的版本中，使用它来显示标记所装饰的方法在self参数中应传记录集。它早已是方法的默认行为，因此添加上仅为清晰起见。在Odoo 9中已经废弃了@api.one装饰器， 因而在Odoo 14中也删去了它。它为理处理记录遍历，这样会对每条记录调用该方法，self参数总是个单体。从Odoo 14起，这两个装饰器都从代码中删除了，不再进行支持。

某些情况下，方法需要对类进行操作，而不是某个具体的记录，像静态方法那样。这些方法使用@api.model装饰，这时self方法参数应为模型的指针，不包含记录。

例如，create()方法使用@api.model装饰器，它并不需要输入记录，仅要一个值字典，用于创建并返回记录。用于计算默认值的方法也要使用@api.model装饰器。

在进一步研究业务逻辑实现之前，我们必须更深入了解数据模型，在此过程中，提供一些通用数据模型模式的示例。

探讨一些数据模型模式

模型用于表示业务文档有一些所需的数据结构。在一些Odoo应用可以看到，如销售订单或发票。

常见的模式是头部/分行数据结构。在借阅请求是会使用到，这样可以借多本书。另一种模式是使用状态或者阶段。这两者存在不同，我们会稍后会讨论并提供参考实现。

最后，ORM API提供一些与用户界面相关的方法。本节中会进行讨论。

使用头部和分行模型

表单视图常见的需求是头部-分行数据结构。例如，销售订单包含多行订单项。对于借阅功能，借阅请求可以有多个请求行，每行为一个借阅项。

在Odoo中实现很简单。需要两个模型来实现头部分行表单视图，一个用于文档头部，另一个用于文档分行。分行模型是一个多对一字段，用于标识所属的头部，而头部模型有一个一对多字段，列举文档中的分行。

在借阅模型中已添加了library_checkout模块，现在需要添加分行。操作步骤如下：

1. 编辑models/library_checkout.py文件，为借阅分行添加一对多字段：

line_ids = fields.One2many(
        'library.checkout.line',
        'checkout_id',
        string="Borrowed Books",
    )

1. 在​​models/__init__.py​​​中添加新模型的文件，如下：

from . import library_checkout
from . import library_checkout_line

1. 然后，添加声明借阅分行模型的Python文件​​models/library_checkout_line.py​​，内容如下：

from odoo import  api, exceptions, fields, models
class CheckoutLine(models.Model):
    _name = "library.checkout.line"
    _description = "Checkout Request Line"
    checkout_id = fields.Many2one(
        "library.checkout",
        required=True,
    )
    book_id = fields.Many2one("library.book", required=True)
    note = fields.Char("Notes")

1. 我们必须添加访问权限配置。编辑security/ir.model.access.csv文件，添加如下高亮部分内容：

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
checkout_user,Checkout User,model_library_checkout,library_app.library_group_user,1,1,1,1
checkout_line_user,Checkout Line User,model_library_checkout_line,library_app.library_group_user,1,1,1,1

1. 然后，我们要对表单添加借阅行。将其添加为notebook微件的第一页。编辑views/checkout_view.xml 文件，在​​​​元素前添加如下代码：

<notebook>
            <page name="lines">
                <field name="line_ids" >
                    <tree editable="bottom">
                        <field name="book_id" />
                        <field name="note" />
                    </tree>
                </field>
            </page>
        </notebook>

借阅表单更新如下：

​​

​​

图8.2：带notebook微件的借阅表单

分行一对多字段显示为父表单视图中的一个列表视图。默认，Odoo会查找用于渲染的列表视图定义，这是任意列表视图的典型定义。如未发现定义，会自动生成一个默认定义。

可以在​​​​内声明具体的视图。在以上代码就这么做的。在line_ids字段元素内，有一个内嵌的​​​​视图定义在该表单中使用。

使用以文档为中心工作流的阶段和状态

在 Odoo 中，我们可以实现以文档(document)为中心的工作流。我们这里说的文档包括销售订单、项目任务或人事申请。所有这些都遵循一个特定的生命周期，它们都在完成时才被创建。每个工作项在文档中记录，按照一系列阶段推进，直至完成。

如果把各阶段以列展示在面板中，把文档作为这些列中的工作项，就可以得到一个看板(Kanban)，一个快速查看工作进度的视图。

实现这些进度步骤有两种方法-状态和阶段：

• 状态为预定义的闭合选项列表。它便于实现业务规则，因其可事先固化。模型和视图对 state 字段有特别的支持，让其易于使用。封闭状态列表有一个劣势，它无法适配自定义流程需求步骤。
• 阶段通过关联模型实现，是一个灵活的步骤列表，可进行配置来满足流程需求。通常使用stage_id字段名实现。阶段列表可以轻易修改，因为我们可以对其删除、添加或重排序。它的劣势是对流程自动化不可靠。因为阶段列表可被修改，自动化规则就无法依赖于具体的阶段 ID 或描述。

在设计数据模型时，我们需要决定是否应使用阶段或状态。如果触发业务逻辑比配置流程更为重要，应优先使用状态，否则应优先选择阶段。

如果无法抉择，有一个两全其美的方法：我们可以使用阶段，并将阶段映射到相应的状态。流程步骤列表可由用户轻松配置，因每个阶段会与一些可靠的状态码相关联，可自如地用于自动化业务逻辑。

图书借阅功能会使用这种方法。为实现借阅阶段，我们要添加library.checkout.stage模型。描述阶段所需的字段如下：

• Name或标题
• Sequence, 用于对阶段列排序
• Fold, 用于看板视图，决定默认是否折叠该列。这通常用于非活跃项目列，如已完成或已取消。
• Active, 允许存档或不再使用的阶段，以妨流程变更 。
• State, 封闭选择列表，用于将每个阶段映射到固定的状态。

实现以上字段我们应添加一个Stages模型，包含模型定义、视图、菜单和访问权限：

1. 添加models/library_checkout_stage.py文件并包含如下模型定义代码：

from odoo import fields, models
class CheckoutStage(models.Model):
    _name = "library.checkout.stage"
    _description = "Checkout Stage"
    _order = "sequence"
    name = fields.Char()
    sequence = fields.Integer(default=10)
    fold = fields.Boolean()
    active = fields.Boolean(default=True)
    state = fields.Selection(
        [("new", "Requested"),
         ("open", "Borrowed"),
         ("done", "Returned"),
         ("cancel", "Canceled")],
        default="new",
    )

以上代码读者应该习以为常了。阶段有一个逻辑排序，所以呈现的顺序很生育。这借由_order="sequence"来实现。我们还看到state字段将每个阶段与一个基本状态相映射，打王者在业务逻辑中可安全使用。

1. 老规矩，在models/__init__.py文件中添加新的代码文件，如下：

from . import library_checkout_stage
from . import library_checkout
from . import library_checkout_line

1. 同样需要访问权限规则。阶段包含设置数据，应仅由管理员用户组编辑。普通用户有只读权限。因此，在security/ir.model.access.csv文件中添加如下高亮代码：

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
checkout_user,Checkout User,model_library_checkout,library_app.library_group_user,1,1,1,1
checkout_line_user,Checkout Line User,model_library_checkout_line,library_app.library_group_user,1,1,1,1
checkout_stage_user,Checkout Stage User,model_library_checkout_stage,library_app.library_group_user,1,0,0,0
checkout_stage_manager,Checkout Stage Manager,model_library_checkout_stage,library_app.library_group_manager,1,1,1,1

1. 接下来需要一个菜单项来浏览阶段的设置。它应当位于应用的配置菜单下。library_app模块暂无此菜单，所以需要对其编辑添加。编辑library_app/views/library_menu.xml文件并新增如下XML：

<menuitem id="menu_library_configuration"
              name="Configuration"
              parent="menu_library"
    />

1. 现在将Stages菜单项加到配置菜单下。编辑library_checkout/views/library_menu.xml文件添加如下XML：

<record id="action_library_stage" model="ir.actions.act_window">
        <field name="name">Stages</field>
        <field name="res_model">library.checkout.stage</field>
        <field name="view_mode">tree,form</field>
    </record>
    <menuitem id="menu_library_stage"
              name="Stages"
              action="action_library_stage"
              parent="library_app.menu_library_configuration" />

1. 我们需要一些操作的阶段，因此在模块中添加一些默认数据。创建data/library_checkout_stage.xml文件加入如下代码：

<odoo noupdate="1">
    <record id="stage_new" model="library.checkout.stage">
        <field name="name">Draft</field>
        <field name="sequence">10</field>
        <field name="state">new</field>
    </record>
    <record id="stage_open" model="library.checkout.stage">
        <field name="name">Borrowed</field>
        <field name="sequence">20</field>
        <field name="state">open</field>
    </record>
    <record id="stage_done" model="library.checkout.stage">
        <field name="name">Completed</field>
        <field name="sequence">90</field>
        <field name="state">done</field>
    </record>
    <record id="stage_cancel" model="library.checkout.stage">
        <field name="name">Canceled</field>
        <field name="sequence">95</field>
        <field name="state">cancel</field>
    </record>
</odoo>

1. 需要在​​library_checkout/__manifest__.py​​文件中进行添加才会生效，如下：

'data':[
        'security/ir.model.access.csv',
        'views/library_menu.xml',
        'views/checkout_view.xml',
        'data/library_checkout_stage.xml',
    ],

成功更新后阶段列表应当如下图所示：

​​

​​

图8.3：阶段列表视图

这就是library_checkout中所需添加的阶段模型，用户也可进行配置。

添加阶段工作流支持模型

下面应在图书借阅模型中添加阶段字段。为保障用户体验，还要再处理两个问题：

• 默认阶段应赋值为new状态。
• 在对阶段分组时，所有可用的阶段都应在场，即使是那些没有借阅的阶段也如此。

这些应该在library_checkout/models/library_checkout.py文件的Checkout类中添加。

查找默认阶段的函数应返回用于默认值的记录：

@api.model
    def _default_stage_id(self):
        Stage = self.env["library.checkout.stage"]
        return Stage.search([("state", "=", "new")], limit=1)

这会返回阶段模型中的第一条记录。因阶段模型按序号排序，它会返回序号最低的那条记录。

在按阶段分组时，会会看到所有的阶段，而不仅仅是那些有借阅记录的。使用的方法返回分组使用的记录集。本例中，返回所有活跃阶段是恰当的：

@api.model
    def _group_expand_stage_id(self, stages, domain, order):
        return stages.search([], order=order)

最后，我们希望添加到借阅模型的stage_id字段，可对default和group_expand属性使用以上的方法：

stage_id = fields.Many2one(
        "library.checkout.stage",
        default=_default_stage_id,
        group_expand="_group_expand_stage_id")
    state = fields.Selection(related="stage_id.state")

stage_id与阶段模型存在多对一关联。默认值由_default_stage_id方法计算，按stage_id的分组使用_group_expand_stage_id方法的结果。

ODOO 10中的变化

在Odoo 10中引入了group_expand属性，在此前版本中没有该属性。

group_expand参数重载了字段分组的方式。分组操作的默认行为是仅查看使用中的阶段，那些没有借阅文档的阶段不显示。但对于stage_id字段，我们希望可用阶段都显示，不管有没有内容。

_group_expand_stage_id()帮助方法返回分组操作使用的分组记录列表。本例中，它返回所有存在的阶段，不管是否包含图书记录。

注：group_expand属性必须为方法名字符串。它不同于其它属性，比如default属性可直接引用方法名或使用字符串。

还添加了state字段。它只是模型中存在阶段相关的state字段，以在视图中使用。这会使用视图中可用的state的特殊支持。

用户界面的支持方法

以下方法最常用于网页客户端中渲染用户界面和执行基础交互：

• name_get()计算显示名称，为在视图中显示关联记录使用的表示每条记录的文件。它返回ID和(ID, name)元组列表.它是display_name值的默认教育处，可扩展用于实现自定义显示，如显示记录名和标识码。
• name_search(name='', args=None, operator='ilike', limit=100)对显示名称执行搜索。用于用户在视图的关联字段中输入生成匹配所输文本推荐记录的列表。它返回一个元组(ID, name)列表。
• name_create(name)创建一条仅带有输入名称的新记录。它在看板视图中配合on_create="quick_create"使用，在其中通过提供名称可快速创建关联记录。可扩展来为通过此功能创建的新记录提供指定默认值。
• default_get([fields])以字典返回待创建新记录的默认值。默认值依赖于变量，如当前用户或会话上下文。可对其扩展添加其它默认值。
• fields_get()用于描述模型字段的定义，在开发者菜单的View Fields选项中也可以看到。
• fields_view_get()在网页客户端中用于获取要渲染的 UI视图的结构。可传入视图的 ID或想要使用的视图类型(view_type='form')作为参数。例如self.fields_view_get(view_type='tree')返回为self模型渲染的树状视图XML结构。。

这些内置的ORM方法可作为实现模型业务逻辑的扩展点。

下一节中我们讨论记录操作（如创建或写入记录）如何触发业务逻辑。

使用 ORM 内置方法

模型定义相关方法可以完成很多任务，但却无法实现有些业务逻辑，所以需要使用到ORM记录写入操作。

ORM 提供对模型数据执行增删改查(CRUD)操作的方法。下面我们来探讨这些写操作以及如何进行扩展支持自定义逻辑。

读取数据的主要方法search()和browse()在​​第七章 Odoo 15开发之记录集 - 使用模型数据​​中已进行讨论。

写入模型数据的方法

ORM 为三种基本写操作提供了三个方法，如下所示：

• .create(values)在模型上创建新记录，values为字典或在批量创建记录时为字典列表。
• .write(values) 使用values字典更新记录集，不返回值。
• .unlink()从数据库中删除记录，不返回值。

values参数是一个字典，映射要写入的字段名和值。这些方法由@api.multi装饰，但create()方法使用@api.model装饰。

Odoo 12中的变化
create()可访问字典列表，而不只是单个字典对象，这在Odoo 12引入 。这样我们也可批量创建数据。这一功能同@api.model_create_multi装饰器进行支持。

有些情况下，我们需要扩展这些方法来在触发方法时运行一些特定的业务逻辑。这种业务逻辑可在主方法执行前或执行后霆。

继承create()方法的示例

我们来学习一个实例。我们不允许新创建借阅记录直接变为已借出或已归还状态。通常应用使用@api.constrains装饰的某个方法来实现验证。但本例只创建记录事件相绑定，很难由常规的验证实现。

编辑library_checkout/models/library_checkout.py文件并添加create()继承方法：

@api.model
    def create(self, vals):
        # 创建前执行的代码，应使用vals字典
        new_record = super().create(vals)
        # 创建后执行的代码，应使用new_record
        if new_record.stage_id.state in ('open', 'close'):
            raise exceptions.UserError("State not allowed for new checkouts.")
        return  new_record

新记录由super().create()调用创建。在此之前，业务逻辑中无法使用新记录，仅可使用values字典，也无法修改以在待创建记录中强制一些值。

super().create()之后的代码可访问新创建记录，且可使用记录功能，如使用点号标记链访问关联记录。上例使用new_record.stage_id.state访问新记录阶段对应的状态。状态是不可由用户配置的，为业务逻辑提供了稳定的值列表。因此，我们可以查找open或done状态并在找到时抛出错误。

继承write()的示例

我们再看一个例子。Checkout模型应记录图书借出的日期，借阅日期，以及归还的日期，关闭日期。这无法使用计算字段实现。而是应继承write()方法来监测借阅状态的变化，然后在相应时刻（变为open或done状态之时）更新日期。

在实现这一逻辑之前，需要创建两个日期字段。编辑library_checkout/models/library_checkout.py文件、添加如下代码：

checkout_date = fields.Date(readonly=True)
    close_date = fields.Date(readonly=True)

在记录发生修改时，在借阅记录进入相应状态时应分别设置checkout_date和close_date字段。为此，我们需要自定义write()方法如下：

def write(self, vals):
        # 写入之前的代码，self为老值
        if "stage_id" in vals:
            Stage = self.env["library.checkout.stage"]
            old_state = self.stage_id.state
            new_state = Stage.browse(vals["stage_id"]).state
            if new_state != old_state and new_state == "open":
                vals["checkout_date"] = fields.Date.today()
            if new_state != old_state and new_state == "done":
                vals["close_date"] = fields.Date.today()
        super().write(vals)
        # 写入之后的代码，可使用更新后的self
        return True

上例中，扩展代码加在super()调用之前，因而是在写入self记录之前。要知道对记录准备做的修改，可以查看vals参数。字典vals中的stage_id是一个ID号，不是记录，所以需要进行扫描获取相应记录，然后读取对应的状态。

比较老状态和新状态来在相应的时刻触发日期值更新。如若可能，我们更希望在super().write()之前修改修改写入的值、更新vals字典，而不是直接设置字段值。下一节中会讲解原因。

继承write()设置字段值的示例

前面的代码仅修改用于写入的值，它不直接对模型字段赋值。这样做安全，但在某些情况下不够。

在write()方法内对某个模型字段赋值会导致无限循环：赋值会再次触发写方法，然后又重复赋值，周而复始。直至Python返回递归错误为止。

有一种避免递归循环的技巧，让write()方法可以对记录字段设置值。这种技巧是设置值前在环境上下文中设置唯一标识，仅在没有标记时才运行设置值的代码。

看实例会更清楚。我们重写前面的示例，让更新在调用super()之后进行：

def write(self, vals):
        # 写入之前的代码，self为老值
        old_state = self.stage_id.state
        super().write(vals)
        # 写入之后的代码，可使用更新后的self
        new_state = self.stage_id.state
        if not self.env.context.get("_checkout_write"):
            if new_state != old_state and new_state == "open":
                self.with_context(_checkout_write=True).write(
                    {"checkout_date": fields.Date.today()})
            if new_state != old_state and new_state == "done":
                self.with_context(_checkout_write=True).write(
                    {"close_date": fields.Date.today()})
        return True

通过这一技巧，扩展代码由一条if语句守护，仅在上下文不存在指定标记时执行。此外，使用了带with_context方法的self.write() 操作执行写入。这组合确保了if语句中代码仅运行一次，在未来的write()调用中不会再次触发，避免了无限循环。

何时(不)继承create()和write()方法

继承create()和write()方法时应认真考虑。

大部分情况下，在保存记录时必须执行一些验证，或是自动计算某些值。对于这些常见情况，有一些更好的选择，列举如下：

• 对根据其它字段自动计算的字段值，使用计算字段。例如在各行值发生变化时计算头部的总计。
• 对于非固定字段默认值，使用方法作为默认字段值。会在赋默认值时进行运算。
• 在一个字段值变化时修改其它字段值，如在用户界面完成，使用onchange方法，如在服务端完成，使用一个新的可写入计算字段。例如，在用户选择客户时，虽然价格列表可由用户稍后修改，我们可以自动设置为客户的价格列表。在使用onchange方法时，仅对表单视图交互有效，无法用于直接写入，但可写入计算字段适用这两种情况。在添加onchange用户界面逻辑一节中进行了更详细的讨论。
• 验证使用constraint方法。在字段值修改时会自动触发，不满足验证条件时会抛出错误。

还有一些情况这些选择都不适用，则需要继承create()或write() ，比如所设置的默认值依赖所创建记录的其它字段时。这时，无法使用默认值方法，因为它无法访问新记录的其它字段。

数据导入、导出方法

导入、导出操作在​​第五章 Odoo 15开发之导入、导出以及模块数据​​已做讨论，也可以通过 ORM API 中的如下方法操作：

• load([fields], [data]) 用于导入数据，由Odoo在导入CSV或数据表数据时使用。第一个参数是导入的字段列表，与 CSV 的第一行对应。第二个参数是记录列表，每条记录是一个待解析和导入的字符串列表。与 CSV 数据中的行和列直接对应，它实现了 CSV 数据导入的功能，比如对外部标识符的支持。
• export_data([fields], raw_data=False)用于网页客户端的导出函数。它返回一个字典，带有包含datas（一个行列表）的数据键。字段名可使用 CSV 文件使用的.id和/id后缀，数据格式与需导入的 CSV 文件兼容。可选raw_data参数让数据值与 Python 类型一同导出，而不是 CSV 文件中的字符串形式。

也可在用户编辑数据时实现对用户界面的自动化。我们在下一节中进行学习。

添加onchange用户界面逻辑

可在用户编辑时网页客户端视图做出修改。这种机制是onchange。由带@api.onchange装饰器的方法实现，在用户编辑某个具体字段时由用户界面视图触发。

从Odoo 13开始，同样的效果使用计算字段的特定表单实现，称为可写计算字段。这种ORM改进旨在避免经典的onchange机制所带来的限制，从长期来看，会完全进行替换。

经典onchange 方法

onchange方法可修改表单中其它值、执行验证、对用户显示消息或对关联字段设置域过滤器，限制可选项。

onchange方法异步调用，返回由网页客户端使用的数据更新当前视图中的字段。

onchange与所触发字段关联，字段以参数传递给@api.onchange("fld1", "fld2", ...)装饰器。

注：api.onchange参数不支持点号标记，例如"partner_id.name"。如若使用，会进行忽略。

在该方法内，self 参数是包含当前表单数据的一条虚拟记录。其为虚拟的原因是它可以在编辑但未存入数据库之时为新记录或修改后的记录。如对self记录设置值，则会在用户界面表单中修改。注意它不写入到数据库记录中，而是提供信息在UI表单中修改数据。

注：onchange方法还有一些其它限制，请参见​​官方文档​​。可写计算字段可用作对onchange方法的全功能替代。详细信息参见带可写计算字段的新onchange一节。

不需要返回值，但可能会返回带警告消息的dict结构在用户界面中显示，或是对表单所设置的域过滤器。

我们做个实例吧。在借阅表单中，选中了图书会员时，请求日期会修改为当天。如果日期发生变化时，会对用户显示一条警告消息，通知用户发生了改变。

实现这一逻辑，编辑library_checkout/models/library_checkout.py文件并添加如下代码：

@api.onchange("member_id")
    def onchange_member_id(self):
        today_date = fields.Date.today()
        if self.request_date != today_date:
            self.request_date = today_date
            return {
                "warning": {
                    "title": "Changed Request Date",
                    "message": "Request date changed to today!",
                }
            }

以上onchange方法在用户界面中设置了member_id字段时触发。实际的方法名无关紧要，但按惯例是在字段名前加onchange_前缀。

在onchange方法内，self表示包含在编辑记录时当前设置的所有记录，我们可与其进行交互 。

方法代码查看当前的request_date是否需要修改。如是，将request_date设置为当天，这样用户可在表单中看到修改。然后向用户返回非阻塞的警告消息。

onchange无需返回任何内容，但可返回包含警告或作用域键的字段，如下：

• 警告的键应描述显示在对话框中的消息，如{'title': 'Message Title', 'message': 'Message Body'}
• 作用域键可设置或修改其它字段的域属性。通过让对多字段仅展示在当下有意义的字段，会使得用户界面更加友好。作用域键类似这样：{'user_id': [('email', '!=', False)]}

带可写计算字段的新onchange

经典onchange机制在由Odoo框架提供的用户体验中扮演着关键角色。但存在着一些重要的缺陷。

其一是它与服务端事件无关联。onchange仅在表单视图请求时起作用，但在实际write()值变更时不会调用。这要求服务端业务逻辑重关相关的onchange方法。

另一不足是 onchange与触发字段相关，但受修改的字段无绑定。对一些小用例，很难扩展，追踪修改源也很困难。

为解决这些问题，Odoo框架扩充了计算字段的功能，让它可以处理onchange用例。我们称这一技巧为可写计算字段。当前仍支持经典onchange，但在未来的版本中会由计算字段替换并进行废弃。

ODOO 13中的变化

可写计算字段在Odoo 13中引入，可在该版本及之后的版本中使用

可写计算字段拥有赋值给它们的计算方法，必须进行存储，必须有readonly=False属性。

我们换由这种方法实现前面的onchange。request_date字段应这样修改：

request_date = fields.Date(
        default=lambda s: fields.Date.today(),
        compute="_compute_request_date_onchange",
        store=True,
        readonly=False,
    )

这是常规的可存储可写字段，但绑定了可由指定条件触发的计算方法。例如，计算方法应在member_id改变时触发。

计算方法_compute_request_date_onchange的代码如下：

@api.depends("member_id")
    def _compute_request_date_onchange(self):
        today_date = fields.Date.today()
        if self.request_date != today_date:
            self.request_date = today_date
            return {
                "warning": {
                    "title": "Changed Request Date",
                    "message": "Request date changed to today!",
                }
            }

@api.depends像对计算字段一样，声明要监测变化的字段。实际提供的字段列表与经典@api.onchange所使用的一致。

方法代码也与onchange方法很相近。在某些情况下完全一致。注意计算字段不保证在每次方法调用时设置。仅在满足某些条件时发生。本例中为原请求日期与当天日期不同。这不同于普通的计算字段规则 ，但可用于可写计算字段。

业务流程强相关的功能有发送邮件或通知用户。下一节中讨论Odoo为此所提供的功能。

消息和活动(activity)功能

Odoo 自带全局的消息和活动规划功能，由 Discuss 应用提供，技术名称为 mail。

mail.thread模型提供消息功能，在表单视图中有一个消息微件，也称之为聊天器（Chatter）。该微件让我们可以记录笔记或向其它用户发送消息。还保存发出的历史消息，同时由自动流程用于记录过程追踪消息。

同一应用还由mail.activity.mixin模型提供活动管理功能。可对表单视图添加活动我邮件，让用户可以计划、追踪活动历史。

添加消息和活动功能

mail 模块提供包含mail.thread抽象类，用于对任意模型添加消息功能。还提供mail.activity.mixin用于添加规划活动功能。在​​第四章 Odoo 15开发之模块继承​​中已讲解了如何使用mixin 抽象类的继承来为模型添加这些继承功能。

执行必要的步骤如下：

1. 编辑​​library_checkout/__manifest__.py​​文件中的depends键来对library_checkout插件模型添加mail模块依赖，如下：

'depends': ['library_member', 'mail'],

1. 要令library.checkout模型继承消息和活动抽象类，编辑library_checkout/models/library_checkout.py文件如下：

class Checkout(models.Model):
    _name = "library.checkout"
    _description = "Checkout Request"
    _inherit = ["mail.thread", "mail.activity.mixin"]

1. 在借阅表单视图中添加消息和活动字段，编辑 library_checkout/ and views/checkout_view.xml文件：

<record id="view_form_checkout" model="ir.ui.view">
        <field name="name">Checkout Form</field>
        <field name="model">library.checkout</field>
        <field name="arch" type="xml">
            <form>
                <sheet>
                    <group>
                        <group>
                            <field name="member_id" />
                            <field name="request_date" />
                            <field name="user_id" />
                        </group>
                        <group>
                            <field name="stage_id" />
                            <field name="checkout_date" />
                            <field name="close_date" />
                        </group>
                    </group>
                    <notebook>
                        <page name="lines">
                            <field name="line_ids" >
                                <tree editable="bottom">
                                    <field name="book_id" />
                                    <field name="note" />
                                </tree>
                            </field>
                        </page>
                    </notebook>
                </sheet>
                <div class="oe_chatter">
                    <field name="message_follower_ids" widget="mail_followers" />
                    <field name="activity_ids" widget="mail_activity" />
                    <field name="message_ids" widget="mail_thread" />
                </div>
            </form>
        </field>
    </record>

完成这些之后，借阅模型就具有了消息和活动字段，并可以使用相应的功能了。

消息和活动字段与模型

消息和活动功能对继承了mail.thread和mail.activity.mixin类的模型添加了新字段，以及所有支持这些功能的模型。以下是添加了的基本数据结构。

mail.thread mixin类添加了两个新字段：

• 关注者：message_follower_ids与mail.follower有着一对多关联，存储接收通知的消息关注者。关注者可以是用户或频道。partner表示某个人或组织。channel不是某个人，而是一个订阅列表。
• 消息：message_ids与mail.message记录存在一对多关联，列出记录历史消息。

mail.activity.mixin mixin类新增如下字段：

• 活动：activity_ids与mail.activity存在一对多关联，存储已完成或已规划的活动。

消息子类型

消息可添加子类型。子类型用于标识指定活动，如所创建或关闭的任务，对于精准控制将什么消息发送给何人很有用。

子类型存储在mail.message.subtype模型中，可通过Settings > Technical > Email > Subtypes菜单配置。

基本的三种消息子类型如下：

• 讨论：带有mail.mt_comment XML ID，用于由消息微件中Send message所发送的消息，默认会发送通知给关注者。
• 笔记：带有mail.mt_note XML ID，用于创建带有Log note XML ID的消息，默认不会发送通知。
• 活动：带有mail.mt_activities XML ID，用于创建带有Schedule activity链接的消息，不发送通知。

应可添加自己的子类型，通常与相关的活动关联。例如，Sales应用添加了两个子类型：报价已发送和销售订单已确认。在消息历史中记录这些事件时会由应用的业务逻辑所用。

子类型允许我们决定何时发送通知以及发送给谁。消息微件右上角的关注者菜单允许我们新增或删除关注者，以及选择接收通知的子类型。下图展示了某一关注者Gemini Furniture的子类型选择表单：

​​

​​

图8.4：选取活跃消息子类型的关注者微件

子类型订阅标记可拖动编辑，其默认值在编辑子类型定义查看Default字段时配置。一经设置，新记录的关注者默认会收到通知。

除内置子类型，插件模块可添加自己的子类型。子类型可以是全局的，也可以只针对指定模型，对于后者，子类型的res_model字段标记其所应用的模型。

发送消息

模块业务逻辑可利用这个消息系统向用户发送通知。

可使用message_post() 方法来发送通知。示例如下：

self.message_post('Hello!')

以上代码添加一条普通文本消息，但不会向关注者发送通知。这是因为默认消息使用Log a Note发布，带有subtype="mail.mt_note"参数。

要让消息还发送通知，需要使用mail.mt_comment子类型，如下例所示：

self.message_post(
    'Hello again!', 
    subject='Hello', 
    subtype='mail.mt_comment')

消息体是HTML格式的，所以我们可以添加标记来实现文本效果，如为加粗，为斜体。

from . import models
from . import wizard

from . import checkout_mass_message

from odoo import api, exceptions, fields, models
class CheckoutMassMessage(models.TransientModel):
    _name = "library.checkout.massmessage"
    _description = "Send Message to Borrowers"
    checkout_ids = fields.Many2many(
        "library.checkout",
        string="Checkouts"
    )
    message_subject = fields.Char()
    message_body = fields.Html()

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
checkout_user,Checkout User,model_library_checkout,library_app.library_group_user,1,1,1,1
checkout_line_user,Checkout Line User,model_library_checkout_line,library_app.library_group_user,1,1,1,1
checkout_stage_user,Checkout Stage User,model_library_checkout_stage,library_app.library_group_user,1,0,0,0
checkout_stage_manager,Checkout Stage Manager,model_library_checkout_stage,library_app.library_group_manager,1,1,1,1
checkout_massmessage_user,Checkout Mass Message User,model_library_checkout_massmessage,library_app.library_group_user,1,1,1,1

<odoo>
    <record id="view_form_checkout_message" model="ir.ui.view">
        <field name="name">Library Checkout Mass Message Wizard</field>
        <field name="model">library.checkout.massmessage</field>
        <field name="arch" type="xml">
            <form>
                <group>
                    <field name="message_subject" />
                    <field name="message_body" />
                    <field name="checkout_ids" />
                </group>
                <footer>
                    <button type="object" name="button_send" string="Send Messages" />
                    <button special="cancel" string="Cancel" class="btn-secondary" />
                </footer>
            </form>
        </field>
    </record>
    <record id="action_checkout_message" model="ir.actions.act_window">
        <field name="name">Send Messages</field>
        <field name="res_model">library.checkout.massmessage</field>
        <field name="view_mode">form</field>
        <field name="binding_model_id" ref="model_library_checkout" />
        <field name="binding_view_types">form,list</field>
        <field name="target">new</field>
    </record>
</odoo>

'data':[
        'security/ir.model.access.csv',
        "wizard/checkout_mass_message_wizard_view.xml",
        'views/library_menu.xml',
        'views/checkout_view.xml',
        'data/library_checkout_stage.xml',
    ],

@api.model
    def default_get(self, field_names):
        defaults_dict = super().default_get(field_names)
        # 在此处为defaults_dict添加值
        return  defaults_dict

@api.model
    def default_get(self, field_names):
        defaults_dict = super().default_get(field_names)
        checkout_ids = self.env.context["active_ids"]
        defaults_dict["checkout_ids"] = [(6, 0, checkout_ids)]
        return defaults_dict

def button_send(self):
        self.ensure_one()
        for checkout in self.checkout_ids:
            checkout.message_post(
                body=self.message_body,
                subject=self.message_subject,
                subtype_xmlid ="mail.mt_comment"
            )
        return True

from odoo import exceptions
raise exceptions.ValidationError("数据不一致")
raise exceptions.UserError("输入错误")

def button_send(self):
        self.ensure_one()
        if not self.checkout_ids:
            raise exceptions.UserError("No checkouts were selected")
        if not self.message_body:
            raise exceptions.UserError("A message body is required")
        for checkout in self.checkout_ids:
            checkout.message_post(
                body=self.message_body,
                subject=self.message_subject,
                subtype_xmlid="mail.mt_comment"
            )
        return True

from . import test_checkout_mass_message

from odoo import exceptions
from odoo.tests import common
 
 
class TestWizard(common.SingleTransactionCase):
    def setUp(self,*args, **kwargs):
        super(TestWizard, self).setUp(*args, **kwargs)
        # 在此处添加测试配置代码
 
    def test_01_button_send(self):
        """发送按钮应对借阅记录创建消息"""
        # 添加测试代码

(env15) $ odoo -c library.conf --test-enable -u library_checkout --stop-after-init

INFO library odoo.modules.module: odoo.addons.library_checkout.tests.test_checkout_mass_message running tests.

class TestWizard(common.SingleTransactionCase):
    def setUp(self,*args, **kwargs):
        super(TestWizard, self).setUp(*args, **kwargs)
        # 配置测试数据
        admin_user = self.env.ref("base.user_admin")
        self.Checkout = self.env["library.checkout"].with_user(admin_user)
        self.Wizard = self.env["library.checkout.massmessage"].with_user(admin_user)
        a_member = self.env["library.member"].create({"partner_id": admin_user.partner_id.id})
        self.checkout0 = self.Checkout.create({"member_id": a_member.id})

def test_01_button_send(self):
        """发送按钮应对借阅记录创建消息"""
        count_before = len(self.checkout0.message_ids)
        # TODO: 运行向导
        count_after = len(self.checkout0.message_ids)
        self.assertEqual(
            count_before + 1,
            count_after,
            "Expected one additional message in the Checkout.",
        )

def test_01_button_send(self):
        """发送按钮应对借阅记录创建消息"""
        count_before = len(self.checkout0.message_ids)
        Wizard0 = self.Wizard.with_context(active_ids=self.checkout0.ids)
        wizard0 = Wizard0.create({
            "message_subject": "Hello",
            "message_body": "This is a message.",
        })
        wizard0.button_send()
        count_after = len(self.checkout0.message_ids)
        self.assertEqual(
            count_before + 1,
            count_after,
            "Expected one additional message in the Checkout.",
        )

def test_02_button_send_empty_body(self):
        """消息体而空时发送按钮报错"""
        Wizard0 = self.Wizard.with_context(active_ids=self.checkout0.ids)
        wizard0 = Wizard0.create({})
        with self.assertRaises(exceptions.UserError) as e:
            wizard0.button_send()

import logging
_logger = logging.getLogger(__name__)

_logger.debug('DEBUG调试消息')
_logger.info('INFO信息日志')
_logger.warning('WARNING警告消息')
_logger.error('ERROR错误消息')

_logger.info(
            'Posted %d messages to Checkouts: %s',
            len(self.checkout_ids),
            str(self.checkout_ids),
        )

INFO library odoo.addons.library_checkout.wizard.checkout_mass_message: Posted 2 messages to the Checkouts: [3, 4]

_logger.debug(
            'Message on %d to followers: %s',
            checkout.id,
            checkout.message_follower_ids)

--loghandler=odoo.addons.library_checkout.wizard.checkout_mass_message:DEBUG

(env15) $ pip3 install watchdog

(env15) $ odoo -c library.conf --dev=all

import pdb; pdb.set_trace()

def button_send(self):
        import pdb; pdb.set_trace()
        self.ensure_one()
        # ...

> /home/vagrant/odoo-dev/custom-addons/library_checkout/wizard/checkout_mass_message.py(24)button_send()
-> self.ensure_one()
(Pdb)

(Pdb) p self.checkout_ids
library.checkout(30,)

pip3 install ipdb

import ipdb; ipdb.set_trace()

sudo apt-get install python-pudb # 使用Debian系统包
pip3 install pudb # 使用 pip，可在虚拟环境中

import pudb; pudb.set_trace()

import pudb; pu.db

ps ax | grep odoo-bin

2650 pts/5  S+   0:00 grep --color=auto odoo
21688 pts/4  Sl+  0:05 python3 /home/daniel/work15/env15/bin/odoo

kill -3 <PID>

kill -HUP <PID>
kill -TERM <PID>