简介
如果你曾在 Odoo 的数据模型里工作，会经常遇到这样的问题：在表单上直接展示某个关联记录的字段值，而不让用户必须跳转到另一个模型去查看。Related 字段正是为了解决这个“就地展示关联信息”的需求而设计的，使用声明式的方式把远端字段拉到当前视图中显示。
与其写一个带 Python 计算逻辑的 computed 字段，Related 字段通过沿着已有的关联链读取最终字段并直接把它暴露出来。对开发者和使用 Odoo Studio 的业务顾问来说，它都是一种省力又直观的工具，可以在不写代码的情况下把上下文信息呈现在表单上。
本文介绍 Related 字段到底保存或反映什么值、在 Odoo 框架中如何运作、怎样通过 Studio 或 Python 创建和配置它，以及在实际业务流程中的合理应用场景。
什么是 Odoo 的 Related 字段
在 Odoo 的 ORM 中，Related 并不是像 Float 或 Char 那样的独立字段类型，而是一种“快捷方式”：沿着点分隔的关联字段链条，映射并展示目标模型的某个字段。Related 字段最终表现为它所指向的终点字段的类型。
举例来说：销售订单有一个 partner_id（Many2one，指向 res.partner）。在销售订单上定义 related='partner_id.country_id'，就能把客户所在国家直接显示出来，而不另存一份独立数据。
对终端用户而言，Related 字段在表单中表现得和普通字段无异：终点字段是文本则显示文本输入框，是 Many2one 则显示下拉，是布尔值则显示勾选框——Related 字段继承了被镜像字段的可视化呈现。
默认情况下，Related 字段是只读且不存储到数据库的。这样它总是显示源记录的最新值，但在没有设置 store=True 时，不能直接用于数据库层面的过滤或搜索。
在 Odoo Studio 中，新建字段时可以选择 Related 类型，逐步选择关联路径，Studio 会自动生成相应字段配置。对顾问而言，这是无需编码就能把上下文信息补到现有表单上的常用手段。
Related 字段的工作原理
Odoo 读取 Related 字段时，会沿着点号分隔的字段链逐步访问。链中除了最后一个字段之外，每一步都必须是关联类型（Many2one、One2many 或 Many2many）；链尾则可为任意字段类型。
下面给出一个在 Python 模块中定义 Related 字段的示例：
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
partner_country_id = fields.Many2one(
related='partner_id.country_id',
string='Customer Country',
store=True,
)
上例中，Odoo 先通过 partner_id 找到 res.partner，然后读取其 country_id，最终在 sale.order 上呈现为一个 Many2one 字段，镜像客户的国家信息。
是否存储（Stored）
这是必须掌握的关键差别。默认 store=False，表示值在读取时即时计算，不会写入当前模型对应的数据表；值不在数据库中占据列。
设置 store=True 后，Odoo 会在源数据变更时将值写入数据库列，从而可以用于过滤、分组和报表，适合需要在列表或分析视图中做查询的场景。
代价是存储的 Related 字段会占用数据库空间，并在源记录变化时触发更新。Odoo 通过依赖追踪自动管理这些更新，但在记录量大、更新频繁的模型上要注意性能影响。
读写权限（只读或可写）
默认 Related 字段是只读的。若设置 readonly=False，则可被编辑，且编辑会沿着链写回到源字段。这个“写回”行为很强大但也容易产生意外：在订单界面改了 Related 字段，实质上是在修改另一张表里的记录。
只有在确实需要“写透到源记录”时才使用可写 Related 字段。它适合做快速编辑场景，但如果用户不清楚其会影响共享记录，容易引发数据一致性问题。
主要可配置属性
以下是配置 Related 字段时常用的参数：
- related：点分链（如 'partner_id.country_id'），这是必需项。
- store：设为 True 时将值持久化到数据库，支持过滤与分组。
- readonly：设为 False 时允许编辑，编辑将回写到源记录。
- string：字段标签，若不设置则默认使用终点字段的标签。
- depends：通常不必手动设置，Odoo 会根据 related 链自动推断依赖；仅在极少数特殊情况需要补充。
与 Odoo ORM 的交互方式
读取 Related 字段会返回链尾字段在关联记录上的值。如果链中任何一步为空（比如 partner_id 未设），Related 字段返回 False，这与 Odoo ORM 的一般关联字段行为一致。
当 Related 字段为存储字段时，能在域、视图和报表中正常使用；未存储的 Related 字段可以显示在表单与列表，但不能作为搜索域的数据库条件（除非服务器端以 Python 方式评估）。
适用的业务场景
Related 字段在实践中非常常见，下面列举五个典型业务用例，便于理解如何把它用到位。
CRM 与销售：在销售订单上显示客户电话
销售团队经常希望在销售订单页面直接看到客户电话号码，而不用跳转到客户记录。对 sale.order 添加 related='partner_id.phone'，即可把电话信息原位展示，便于在跟进电话时快速查看；在 Odoo Studio 下，这类改动通常只需一分钟即可完成。
会计：发票行显示公司的币种
在多公司环境中，会计人员有时需要在发票行层级看到公司币种以便统计报表。related='move_id.company_id.currency_id' 这种跨两层关联的链可以把币种拉到发票行。尽管三层链是有效的，但为了性能和可维护性，建议尽量缩短链条。若要在报表中按币种筛选，记得将该字段存储起来。
库存：在库存移动行显示产品分类
仓库操作人员在处理库存移动时，常常希望直接看到商品的分类以便分拣、分组或报表。对 stock.move.line 添加 related='product_id.categ_id'，并设置 store=True，就可以在库存报表中按产品分类汇总出入库数据，适合品类繁多的企业。
制造：工单组件上显示产品内部编码
生产现场的操作员在装配时需要确认零件的内部料号，避免错拿相似件。把 product_id.default_code 作为 Related 字段放到 mrp.workorder 的组件行上，可以把内部料号直接展示在操作界面，降低出错率，提高生产效率。
工时与项目：在工时行上显示员工部门
项目经理在做成本归集或分析时，往往需要知道填写工时的员工属于哪个部门。对 account.analytic.line（工时模型）添加 related='employee_id.department_id'，并存储后即可在项目分析中按部门筛选和分组，增强 Odoo 在资源分配与成本分析方面的能力。
如何创建或定制 Related 字段
添加 Related 字段的三种常见方法
通过 Odoo Studio（无代码）
Odoo Studio 能让你不写代码就新增 Related 字段，适合快速交付和顾问临时需求。操作步骤如下：
- 打开主菜单中的 Odoo Studio。
- 定位到目标表单界面。
- 点击“添加字段”，选择“Related 字段”。
- 按步骤在可选字段中点击选择完整的关联路径。
- 填写标签并配置是否存储、是否只读等属性。
- 保存并关闭 Studio。
Studio 会自动在字段名加上 x_studio_ 前缀并把字段放到视图中，这是在不改底层代码或数据库结构下给界面补充上下文信息的高效方式。
通过自定义模块（用 Python）
对于需要版本控制、可重复部署或纳入开发流程的改动，建议在自定义模块中以 Python 定义 Related 字段：
from odoo import fields, models
class StockMoveLine(models.Model):
_inherit = 'stock.move.line'
product_category_id = fields.Many2one(
related='product_id.categ_id',
string='Product Category',
store=True,
)
定义好字段后，把它加入相应的视图 XML 中以在界面显示。模块安装或升级时 Odoo 会自动创建相应的数据库列；这是可维护性和多环境部署的标准做法。
通过 XML-RPC API 创建
在通过脚本或远程配置进行批量管理的部署中，可以用 XML-RPC 接口创建 Related 字段，方法是向 ir.model.fields 提交带 related 属性的字段定义：
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_partner_country_id',
'field_description': 'Customer Country',
'model_id': sale_order_model_id,
'ttype': 'many2one',
'relation': 'res.country',
'related': 'partner_id.country_id',
'store': True,
'readonly': True,
'state': 'manual',
}]
)
通过 API 创建时必须手动指定 ttype 与 relation，因为 API 不会像 Python ORM 那样从链中推断类型。这种方式适合把字段变更纳入自动化部署或远程配置管道。
最佳实践
最佳建议汇总
1）如果需要在筛选或分组中使用该字段，就一定要把它设为 store=True；否则数据库无法高效地做查询，只能靠在内存中逐条判断，扩展性差。
2）保持链条尽量短。两层关系清晰且性能好；太深的链容易出错且难维护。遇到复杂逻辑时，优先考虑用 computed 字段写明晰的 Python 逻辑。
3）明确 readonly=False 的含义：可写的 Related 字段并不会在当前模型保留一份副本，它会修改源记录。确保业务方理解这一点并同意后再开放编辑权限。
4）把 Related 字段当作“展示”工具，而不是数据副本。如果你需要一份可以独立于来源变化的值，应使用普通字段并通过 onchange 或自动化动作初始化，而不是靠 Related 字段去复制数据。
5）注意访问权限影响。Related 字段会透过关系去读取另一个模型的记录；如果当前用户对那个模型没有读权限，字段会返回空值。设计时要确认相关角色的访问权限以免造成界面上的混淆。
常见错误与应对策略
在列表视图上对未存储的 Related 字段做筛选
最常见的失误之一是：在列表或搜索视图中使用 Related 字段作为过滤条件但忘记设置 store=True。未存储的 Related 字段无法作为数据库级别的筛选条件，结果要么报错要么返回空集合。计划作为过滤或分组依据的 Related 字段务必存储。
意外的写回行为
常见陷阱
由 Odoo Studio 添加的 Related 字段若被设为可编辑，经常会引发业务人员以为改的是当前记录的错误认知，但背后实际修改的是共享的源记录。启用可写 Related 字段前务必与业务方确认他们是否接受该写回逻辑。
链中中间字段为空未处理
链上任何一步为空都会让 Related 字段返回 False。表单上表现为空白；在 Python 计算或自定义方法中读取时若未显式处理 False，会触发类型错误。测试时要覆盖空值场景，避免生产环境意外暴露。
在需要逻辑处理时滥用 Related 字段
Related 字段适合直接镜像单一值；当需要转换、条件判断或合并逻辑时，应使用 Computed 字段并在 Python 中实现。用 Related 去做复杂逻辑通常只能靠 hack 走捷径，难以维护且易在升级中损坏。
大量存储型 Related 字段带来的性能问题
每个存储型 Related 字段在源值变动时都会触发写操作。如果在一个大表上加了很多 store=True 的 Related 字段，且这些源字段变动频繁，会给数据库写入造成很大压力。大型部署下应先评估性能影响，必要时将某些字段保留为非存储的展示字段。
总结
Related 字段是 Odoo 框架中非常实用的工具，能够在不复制数据的前提下把关联记录的字段就地展示。它支持在视图中原位显示、可选持久化以便筛选报表，并能根据需要设置为可写以实现写透行为。
掌握何时设置 store=True、何时允许写回、以及如何处理链中空值，可以避免许多常见数据问题。不论你是编写自定义模块的开发者、使用 Studio 的顾问，还是负责配置与部署的技术负责人，了解 Related 字段的工作方式都会让 Odoo 模型设计更稳健。
结语
在构建或扩展 Odoo 数据模型时，Related 字段应作为与你熟悉的 Computed、Many2one 等字段一样的重要工具纳入你的工具箱。
关于我们
在 Dasolo，我们帮助企业在销售、运营、财务等领域实施、定制并优化 Odoo。无论是数据模型设计、界面字段定制，还是用可维护的代码扩展 Odoo，我们都能提供支持。
如果你需要在 Odoo 上做方案设计或实施支持，欢迎联系我们。 联系我们 让我们一起讨论如何支持你的 Odoo 项目。