权限

ObjectOS 借鉴企业软件二十年来行之有效的分层访问模型：身份 → 岗位 → 权限集 → 记录访问 → 字段安全。每一层回答一个不同的问题，你可以忽略用不到的层。（ObjectStack 13 将旧的角色与简档概念合并为岗位——参见岗位。）

一张图说明模型

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Positions            Which job functions do they hold?
        ↓
Permission sets      What CAN they do — apps, objects, fields, system?
        ↓
Record access        WHICH records can they touch?
        ↓
Field security       For those records, which FIELDS are readable / writable?

每一层都由 security 插件强制执行。简单应用可以只使用权限集（不用岗位、不用共享规则），等需求出现时再增补其余层。

第 1 层 —— 身份

身份对象存在你的项目数据库中。最重要的几个：

在多租户部署中：

• 用户作用域限定到项目数据库。
• 会话作用域限定到项目主机名。
• 行级检查使用当前用户所在组织和权限。
• 控制面用户不会自动成为业务用户——必须通过平台 SSO 或显式预置进行映射。

你可以在运行时通过 Console（/_console/）创建/管理这些对象，也可以在 objectstack.config.ts 中为全新环境种入。

第 2 层 —— 岗位

岗位对职能建模（"销售经理"、"支持坐席"）。岗位是扁平的——层级结构位于业务单元树上，因此共享规则和报表表达的是"记录所有者所在单元及下级单元"之类的关系。两个预置的受众锚点 everyone（所有已认证用户）和 guest（匿名调用者）让你无需自定义回退逻辑即可绑定基线权限集。用岗位按职能分发权限集；扁平团队可以不建自定义岗位。

参见岗位。

第 3 层 —— 权限集

权限集是授予能力的主要方式。它们直接附加到用户，或通过岗位附加。

它们授予什么

对象权限标志

这些是 security 插件实际检查的标志名称：

viewAllRecords 与 modifyAllRecords 是对该对象的租户级超级用户授权。仅在显式的管理权限集中使用，不要放进任何面向普通用户的岗位。

参见 Permission Sets。

第 4 层 —— 记录访问

对于没有 viewAllRecords 的用户，他们能看到哪些行？

模型支持：

• 隐式所有权（用户创建或拥有的行）
• 共享规则（声明式 —— "团队 A 能看到团队 A 的记录"）
• 显式共享（sys_record_share 行——一次性共享，可授予用户、岗位或"单元及下级单元"）
• 组织作用域（行的 org_id 与用户所在组织匹配）

自 ObjectStack 13 起，带有所有者字段的自定义对象默认使用私有共享模型——需要开放时请显式声明 sharingModel。

参见 Record Access。

第 5 层 —— 字段安全

即使用户能看到记录，单独的字段也可以是：

• 隐藏 —— 字段被从 API 和 UI 响应中剥离。
• 只读 —— 字段返回，但写入会被拒绝。

字段安全是按对象 + 按权限集设定的。典型用途：

• 把 sys_user 上的 salary 对 HR 之外的所有人隐藏。
• 把 external_account_id 对支持代表设为可读但不可编辑。

它在与对象权限相同的求值器中强制执行，因此在 REST、ObjectQL 和 Console 上统一生效。

从哪里入手

诊断与审计

• 解释引擎（explain(principal, object, operation)）按顺序报告每一层的判定结果——所需权限、对象 CRUD、字段安全、OWD 基线、共享、行级安全——并给出逐层归因。Console 将其呈现为"该用户为何能访问？"面板。解释其他用户需要 manage_users 能力。
• /_console/ 显示任一用户当前评估出的有效权限。
• 审计日志（sys_audit_log）记录权限敏感变更——授权、岗位分配、权限集编辑。
• 被拒请求记录失败的具体规则（对象权限 vs 记录访问 vs 字段安全），便于支持人员快速回答"为什么我看不到这个？"。