Odoo 装好之后，员工的默认权限是什么？

系统上线、用户账号建好之后，每个员工登录后能看到的数据范围，由 Odoo 的默认配置决定。

本文列出其中几项默认值，说明这些默认值的来源，以及收敛它们时会遇到的层级约束。

本文所述行为在 Odoo 19 上验证。权限相关的默认值在版本之间可能变化，自查结果与本文不一致时，先确认版本。

1. 默认可见范围

以下为未经任何额外配置的默认状态：

1. 成本类数据 —— 产品成本及其对应的库存估值，对全部内部用户可见。成本字段本身设有字段级权限组，但默认值为「所有内部员工」，在实际效果上不构成限制。
2. 联系人 —— 全部内部用户可读。启用 CRM 后，销售用户对全部联系人具有编辑权限。

成本的出口不止产品表单上的字段显示。列表视图的分组聚合、搜索过滤，都是同一份数据的不同读取方式。

门户用户（Portal）不属于内部用户，不在上述范围内。

2. 这一范围的来源

Odoo 的读权限分三层：

1. 模型级 —— 能否读取这个模型。
2. 记录级 —— 能读取这个模型下的哪些记录。
3. 字段级 —— 能读取记录中的哪些字段。

业务单据的计算与校验在服务端执行，且以当前用户的身份执行。由此形成一条链：

单据引用主数据 → 引用即读取 → 用户要完成操作，就必须持有对应主数据的读权限。

可见范围因此不是按「谁需要知道」划定的，而是被操作需求撑开的。仓库用户为完成发货、会计为完成开票，都必须能够读取客户记录。这两个岗位在业务上不需要客户的联系方式，但在权限上无法与「能读取这条记录」分开。

由此得出本文的核心约束：收敛可见性的难点不在于能否关掉，而在于关掉之后单据能否照常开出。

3. 同一原因的另一种形式：权限组捆绑

除了记录读取，可见范围还会通过权限组的捆绑粒度扩散。到岸成本是一个完整的例子：

1. 到岸成本功能位于库存模块下，其访问权限属于库存管理员权限组。
2. 会计在录入供应商账单时，需要在产品行上标记该行是否计入到岸成本。
3. 执行这一标记动作所需的权限，挂在库存管理员组上。
4. 为使会计能够完成这一步，需要为会计用户授予库存管理员权限。
5. 授予之后，该权限组覆盖的其他范围一并开放。

一个具体的操作动作与一整组功能绑定在一起，为获得这个动作，必须接受整组的可见范围。这与第 2 节是同一个成因在不同层级上的表现。

4. 收敛方式一：记录级规则

第一种收敛方式是增加记录级规则，例如限定销售用户只能看到自己负责的联系人。

实测结果：

1. 功能上成立。 列表最终只显示该用户负责的联系人。
2. 列表加载过程中会抛出权限错误。 加载完成后不影响使用，过程中的报错无法消除。

而在其他岗位上，冲突更直接：

会计与仓库用户为了开票和发货，必须持有对全部联系人记录的读权限。记录级规则一旦收紧到「只看自己相关的」，这两类用户的单据就开不出来；不收紧，他们可读取的就是全部联系人。

记录级收敛与单据操作能力直接冲突，两者之间没有中间状态。

5. 收敛方式二：字段级限制

记录必须可读，收敛只能退到字段层。

字段级限制作用在数据读取层，而不是界面显示层。因此一次设置会同时关闭四个出口：

1. 直接读取字段值
2. 列表视图按该字段分组、求平均、求和
3. 用搜索过滤条件对数值做区间试探，逐步逼近具体数值
4. 数据导出中的字段选择

不在权限组内的用户触发上述任一路径，得到的是权限错误，而不是一个空值。

这一方式的约束条件在于计算依赖。

凡是在单据生成时需要自动带出或计算成本的模块，其计算同样以当前用户身份执行。将成本字段的权限组收窄之后，用户在不具备该权限的情况下执行这些操作会中断。销售订单、制造订单等引用主数据成本的单据模块，都属于这一类。

不受影响的部分同样需要确认：库存计价与会计分录以系统身份计算，收窄字段权限组不影响发货与开票的估值结果。

6. 判断准则

把第 4、5 节的结果合起来，可以得到一条可复用的判断依据：

一个字段能否在数据层收敛，取决于是否有单据在生成时需要自动读取它。

• 需要 —— 数据层收敛会中断正常业务操作，只能退到界面层隐藏。成本属于这一类。
• 不需要 —— 可以在数据层关闭。联系人的电话、邮箱属于这一类。

联系人的实际落点因此是分层的：

1. 记录层不动 —— 保住会计与仓库的单据操作能力。
2. 列表视图收敛 —— 减少与岗位无关的批量浏览。
3. 电话、邮箱做字段级限制 —— 这两个字段不参与单据计算，可以在数据层关闭。

邮箱需要与电话同等对待，原因是它同时是外部用户在门户的注册标识，性质上不只是一项联系方式。

结论不是某一层更好，而是每个字段的收敛层级由它被引用的方式决定，需要逐字段确认，无法统一处理。

7. 界面层隐藏的边界

界面层隐藏作用的位置是某一个视图的定义，它把字段从这个视图的结构里移除。

而搜索面板中的自定义筛选与自定义分组，读取的不是视图定义，而是模型的字段清单。字段清单来自模型本身，与该字段在哪些视图上出现无关。

因此字段从表单和列表上移除之后，它仍然出现在自定义筛选与自定义分组的可选项中。对成本设置一个大于或小于的过滤条件，通过观察哪些记录被筛掉，可以在数值始终不显示的情况下逐步逼近它。

这是两种做法的根本差别：字段级限制把字段从模型的字段清单中移除，四个出口同时关闭；界面层隐藏只改变某一个视图的显示内容。

第 5 节列出的四个出口中：

• 数据导出 —— 导出权限属于主数据权限配置的一部分，通常不随普通岗位一并授予，这一出口一般已由另一项配置关闭。
• 分组聚合与搜索过滤 —— 不需要额外权限，任何能够打开该列表的用户都可以使用。

因此两种诉求需要分别评估：

1. 减少无关岗位的日常可见范围 —— 界面层隐藏有效。
2. 使数据在系统内不可读取 —— 需要字段级限制，而字段级限制受第 6 节的准则约束。

对成本这类既受计算依赖约束、又需要控制范围的数据，可行的处理是把界面层收敛与操作审计结合，而不是依赖单一开关。

8. 自查清单

以下步骤可在自己的系统上直接执行，不需要开发权限：

1. 用一个只具备销售权限的普通内部用户登录。
2. 打开任意产品，查看采购或库存标签页中的成本字段是否显示。
3. 回到产品列表视图，尝试按成本分组，或在搜索面板中对成本添加自定义筛选。
4. 打开联系人应用，确认可见记录数是否等于公司联系人总数。
5. 换用只具备会计权限的用户，重复第 4 步。
6. 检查会计用户是否持有库存管理员权限，以及该权限是否为处理到岸成本而授予。

第 4、5 步的结果与第 2 节描述的机制直接对应：可读取范围由单据操作需求决定，与岗位是否需要知道无关。

9. SuiteState 的方案

本文内容来自 SuiteState 自身在 Odoo 上运营批发业务时的实测。顺序是：先用记录级规则收敛联系人，遇到列表加载报错，以及会计与仓库岗位无法开单；再改为字段级限制成本，遇到单据计算中断。两次结果决定了最终的实现方式，也就是第 6 节的准则。

由此形成四个模块，各自对应文中的一节：

• Cost Guard —— 成本字段的界面层收敛。成本受单据计算依赖约束，无法在数据层关闭（第 5 节），该模块处理的是减少无关岗位的日常可见范围，不作为数据不可读取的保证。
• Contact Guard —— 联系人的分层收敛：记录层保持不动以维持单据操作能力，列表视图收敛，电话与邮箱做字段级限制（第 6 节）。
• Landed Cost Access —— 将到岸成本的标记权限从库存管理员组中独立出来，使会计能够在账单上完成标记，而不必接受整个库存管理员组的可见范围（第 3 节）。
• Inventory Access —— 库存相关数据的访问范围划分。

这些模块处理的是可见范围的划分，不改变 Odoo 的权限机制本身。第 5 节的约束对任何实现方式都成立：成本无法在数据层收敛，是引用结构决定的，不是配置问题。

默认值是系统给出的起点。它与企业实际的信息边界是否一致，需要逐项确认。