NocoBase 操作权限配置详解数据表资源权限、数据范围与字段级控制【免费下载链接】nocobaseNocoBase is an open-source AI no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase操作权限是 NocoBase 界面搭建体系中控制按钮可见与可执行的核心机制。本文围绕 NocoBase 2.0 中由数据表资源权限主导的操作权限模型讲解全局权限、特定数据表操作权限、数据范围所有数据 / 自己的数据与字段权限的配置方法与判定逻辑并结合nocobase/plugin-acl与nocobase/core/acl的源码揭示其底层判定原理。读完本文你将掌握如何为不同角色配置统一的 CRUD 操作权限并在同一数据表的不同页面、弹窗与区块中保持一致。操作权限概述在 NocoBase 2.0 中操作权限目前主要由数据表资源权限控制用于统一管理不同角色对数据表的增Create、查View、改Update、删Delete等基础操作权限数据表资源权限作用于数据源下的整个数据表确保角色在不同页面或弹窗中不同区块对该表的相应操作保持一致权限。这是一种表级 动作级的通用权限模型规则统一、易于维护。独立操作权限用于细化控制不同角色可见的单个操作如触发工作流、自定义请求、外部链接等属于操作级粒度控制使不同角色可以执行特定操作而不影响整张数据表的权限配置。在本文所基于的文档版本中该能力以注释形式保留尚未作为主推能力展开配置时以数据表资源权限为主。这种以数据表资源权限为核心的模型回答了一个常见问题为什么同一张数据表的编辑按钮在 A 页面可见、在 B 页面却不可见答案在 NocoBase 中通常是两个区块绑定的是不同的数据表资源或者角色对该表的权限配置不同——而不会出现同一张表、同一个动作在不同位置权限不一致的情况。数据表资源权限按 CRUD 维度划分NocoBase 权限体系将数据表操作权限基本按 CRUD 维度划分以保证权限管理的一致性和规范性。四个基础维度如下权限维度覆盖的操作影响范围新增权限Create新增操作、复制操作等所有新增相关操作只要角色拥有该表的新增权限新增/复制等操作在所有页面或弹窗中都可见删除权限Delete表格区块中的批量删除、详情区块上的单条记录删除无论入口在哪里删除权限保持一致更新权限Update编辑操作、更新记录操作等更新类操作编辑按钮/表单的可见与可执行统一受控查看权限View数据可见性仅当角色拥有查看权限时相关数据区块表格、列表、详情等才可见这种通用权限管理方式适用于标准化的数据权限控制核心价值在于在不同页面、弹窗、区块中对同一数据表的相同操作遵循一致的权限规则具备统一性和可维护性。例如只要角色拥有某表的新增权限那么该表的新增操作和复制操作在所有页面或弹窗中都可见删除权限无论面对表格区块中的批量删除还是详情区块上的单条删除判定结果都一致查看权限直接决定该数据表的数据区块表格、列表、详情等是否渲染可见。从源码看这四个维度并非硬编码字符串而是由 ACL 的可用动作注册表驱动。acl-available-action.ts 定义了AvailableActionOptions其中aliases用于建立动作别名例如编辑可以关联到多个底层 actionallowConfigureFields用于标记该动作是否允许进一步配置字段级权限——这正是下文字段权限得以实现的基础export interface AvailableActionOptions { type?: new-data | old-data; // deprecated displayName?: string; aliases?: string[] | string; resource?: string; // 对新数据进行操作 onNewRecord?: boolean; // 允许配置字段 allowConfigureFields?: boolean; }在角色配置界面中添加、查看、编辑、删除、导出、导入等可用动作即来自 available-actions.ts 提供的availableActions资源它遍历acl.getAvailableActions()后返回动作名称与选项供前端权限表单渲染name: availableActions, async handler(ctx) { const acl ctx.app.acl as ACL; const availableActions acl.getAvailableActions(); ctx.body Array.from(availableActions.entries()).map(([, { name, options }]) ({ name, options, })); },全局操作权限作用于数据源下所有数据表全局操作权限对该数据源下的所有数据表生效按照资源类型即 CRUD 动作维度划分。配置入口位于角色的权限配置页属于最粗粒度的授权勾选某个动作后该数据源内所有数据表都放行对应操作。全局权限同样支持数据范围维度配置所有数据 / 自己的数据。在角色配置界面中全局操作权限与数据表操作权限形成兜底 细化的层级关系全局权限定义默认行为特定数据表权限在其之上进行覆盖。详见 配置权限 中全局操作权限一节。特定数据表操作权限细化到单表与字段特定数据表操作权限高于数据源通用权限可针对特定数据表的资源访问进行自定义权限配置分为两个方面操作权限与数据范围操作权限包括添加、查看、编辑、删除、导出、导入操作根据数据范围维度进行配置所有数据允许用户对数据表中的所有记录执行操作自己的数据限制用户仅对自己创建的数据记录执行操作。自己的数据这一范围在底层如何判定核心实现在 acl-available-strategy.ts 的predicate定义中export const predicate { own: { filter: { createdById: {{ ctx.state.currentUser.id }}, }, }, all: {}, };可以看到自己的数据被翻译为一条附加过滤条件createdById等于当前登录用户的 ID{{ ctx.state.currentUser.id }}是运行时模板变量在执行时替换为请求上下文中的当前用户。也就是说当角色仅拥有自己的数据范围时ACL 会在查询/操作时自动追加createdById 当前用户ID的过滤条件从数据层面上隔离他人记录。所有数据则对应空过滤{}不做任何限制。字段权限字段权限允许对每个字段在不同操作中进行权限配置。例如某些字段可以配置为只允许查看而不允许编辑——即可见但不可写。这一能力由上文AvailableActionOptions.allowConfigureFields开关控制只有声明了该选项的动作典型如 view / edit / export才允许展开字段级配置。此外针对关联字段RelationField还有专门的优化逻辑。在 plugin-acl 服务端 server.ts 中beforeGrantAction钩子会在授权动作时处理字段参数当动作是view或export时若配置的字段列表中包含关联字段会将其转换为关联字段形式后再写入 ACL 参数从而保证带关联字段的查看/导出权限能够正确解析this.app.acl.beforeGrantAction((ctx) { const actionName this.app.acl.resolveActionAlias(ctx.actionName); const collection this.app.db.getCollection(ctx.resourceName); if (!collection) return; const fieldsParams ctx.params.fields; if (!fieldsParams) return; if (actionName view || actionName export) { const associationsFields fieldsParams.filter((fieldName) { const field collection.getField(fieldName); return field instanceof RelationField; }); // ... 将关联字段写入授权参数 } });底层判定流程角色、策略与资源的装配理解操作权限的配置界面后再看它是如何被装配与执行的有助于排查权限不生效的问题。在 server.ts 中writeRoleToACL负责把数据库中的角色配置写入内存中的 ACL 实例流程为调用role.writeToAcl({ acl, withOutStrategy: true })写入角色及其可用策略如允许配置界面等通用权限遍历该角色的resources即数据表资源权限配置对每个资源调用writeResourceToACL把动作、数据范围与字段配置逐一写入 ACL。其中允许配置界面 / 允许安装插件 / 允许清除缓存等通用权限在 配置权限 文档中有明确说明允许配置界面控制是否出现 UI 配置按钮admin 角色默认启用允许安装、激活、禁用插件控制是否可访问插件管理器界面admin 角色默认启用允许配置插件控制是否可配置插件参数或管理插件后台数据admin 角色默认启用允许清除缓存重启应用系统运维权限默认不启用新增菜单项默认允许访问默认开启。而角色本身由 角色管理 支撑初始化安装的应用内置Admin和Member两个角色拥有不同默认权限一个用户可以被分配多个角色并在个人中心进行角色切换进入系统时的默认角色优先级为上一次切换的角色 第一个角色系统默认角色。与其他权限配置的关系操作权限只是 NocoBase 权限体系的一部分与它协同工作的还有菜单访问权限以菜单为维度控制访问权限决定用户能否进入某个菜单页面插件配置权限控制特定插件参数的配置权限勾选后管理中心将出现对应插件的管理界面角色级通用权限即上文提到的允许配置界面、允许安装插件等系统级开关。实际使用中操作权限控制对数据能做什么菜单权限控制能进哪些页面插件权限控制能管理哪些插件三者叠加才构成一个角色完整的访问边界。关于这些内容的完整配置说明可继续阅读 配置权限。小结NocoBase 2.0 的操作权限以数据表资源权限为核心按 CRUD 维度划分Create / View / Update / Delete通过全局权限兜底 特定数据表权限细化的层级结构实现统一且灵活的授权数据范围所有数据 / 自己的数据在底层被翻译为createdById 当前用户ID的过滤条件见 acl-available-strategy.ts字段权限则依赖allowConfigureFields标记实现可看不可改等细粒度控制。对开发者和实施者而言理解这套模型意味着当某个角色的按钮该显示却不显示或不该显示却显示了时优先检查角色在该数据表上的对应 CRUD 权限与数据范围配置即可快速定位问题。【免费下载链接】nocobaseNocoBase is an open-source AI no-code platform for building business systems fast. Instead of generating everything from scratch, AI works on top of production-proven infrastructure and a WYSIWYG no-code interface, so you get both speed and reliability.项目地址: https://gitcode.com/GitHub_Trending/no/nocobase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考