限制规则

提供的能力

@nocobase/app-plugin-authz-restriction-rules 限制规则收窄指定主体已经取得的记录范围。规则中的选择表示“仍然允许访问的记录”，而不是需要屏蔽的记录；多条匹配限制共同生效。

应用负责规则管理页；运行时注册之外还需组合授权工厂，规则才能参与业务访问决策。

使用场景与示例

业务示例

例如实习生已有订单读取权限，但只能处理非保密订单。为实习生主体配置读取限制，选择“非保密订单”。即使共享规则追加了某份保密订单，这份订单也不会越过限制。

先确认主体拥有目标操作，再配置范围；最后分别检查允许记录、范围外记录和直接 API 调用。业务查询必须落实授权服务返回的数据策略，规则才会影响实际查询。

开发提示词（交给当前应用目录中的 Coding Agent）：

请使用 @nocobase/app-plugin-authz-restriction-rules，将实习生已有订单读取范围限制为非保密订单，并验证共享不能绕过限制。
保留已有授权扩展，接入规则管理页面及相应设置权限。
先检查主体是否拥有读取操作，再配置记录范围，不通过新增管理员权限绕过限制。
用普通用户验证允许记录、范围外记录和直接 API 请求。

完成标志：实习生只看到非保密订单，即使共享了保密订单也不能读取。

重要原理与实现

以下是实现本例时的接入位置与预期界面变化；它们是开发说明，具体文件名沿用当前应用结构。

接入与配置

在权限管理基础上注册本插件的 Client、Server 入口，执行迁移；还要将工厂加入应用的 server/config/authorization.ts：

import { restrictionRules } from '@nocobase/app-plugin-authz-restriction-rules/server';

// 合并到现有授权配置，保留其他已启用的扩展。
plugins: [restrictionRules()]

运行时注册负责语言资源和数据库迁移，配置工厂才负责安装规则能力与 HTTP 接口。漏掉工厂时，仅安装包不会使规则生效。

配置与使用规则

选择支持全部记录、指定记录 ID 或已注册的 recordAccess。多条限制取交集，因此一条规则选择全部记录也不会取消其他限制。删除限制可能扩大访问范围，需要重新验证受影响主体。

规则管理接口位于 /api/authorization/restrictionRules，提供列表、创建、更新和删除，以及选项、主体或记录选择所需的接口。应用负责管理页面，插件不自动注册页面。访问需要 settings:authorization.restriction-rules 的相应 read、create、update 或 delete 权限。

应用通过受保护的接口保存规则。可信服务端代码也可以使用授权服务上的 restrictionRules API；自行封装 HTTP 接口时，需要保留权限检查与输入校验。

AI 开发的约束与验证

本插件的开发约束

• 选择表示仍允许的记录，多条限制取交集；删除规则可能扩大访问，需要重新检查。
• 规则改变记录范围，不授予页面、操作或字段权限；检查服务端查询是否真正应用策略。
• 用非 unrestricted 身份验证规则叠加、撤销和直接访问，不能只测超级管理员。

使用边界

规则不会授予页面、操作或字段权限，也不会自动打开关联记录。默认范围和共享范围合并后，仍受限制规则约束。unrestricted 身份跳过这些范围规则，因此不能只用超级管理员验证普通用户的结果。

相关文档：权限管理、默认数据范围、共享规则、限制规则。

上述检查是接入后的验收要求，不表示本文已完成运行验证。让 Agent 报告实际改动、执行过的检查和未验证项；项目指引、Skills 与通用检查流程见持续开发应用和测试。

源码依据：插件公开入口与实现。