ToolJet 权限体系深入解析基于用户组User Groups的 RBAC 访问控制实战指南【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet在 ToolJet 中权限管理以基于角色的访问控制RBAC为核心管理员负责邀请用户进入工作区Workspace并将他们分配到特定的用户组Groups每个组都绑定一组权限Permissions用来决定成员对 App、文件夹、工作区变量等资源的访问级别。本文将以 ToolJet 2.50.0-LTS 版本的官方文档 permissions.md 为主线结合仓库中server/src/modules/group-permissions的源码实现系统讲解默认组、自定义组、细粒度权限以及实际运维中的落地步骤帮助你像管理员一样精确控制谁能在你的 ToolJet 工作区里做什么。一、RBAC 核心模型资源、组与权限的关系在 ToolJet 中整个权限体系由三类基本元素构成理解了这三者的关系就理解了权限系统的全貌元素说明Users用户工作区成员每个用户关联一个邮箱可以被加入一个或多个组Groups用户组权限的载体。默认存在All Users与Admin两个组此外可创建如 Support、Engineering 等自定义组Resources资源管理员可以设置权限的对象包括Apps应用、Folders文件夹与Workspace Variables工作区变量Permissions权限施加在资源上的操作能力核心是Create创建、Update更新、Delete删除在 App 级别则细化为View查看与Edit编辑这一模型在服务端源码中有着精确的对应。在 server/src/modules/group-permissions/constants/index.ts 中定义了组的类型与内置角色export enum GROUP_PERMISSIONS_TYPE { DEFAULT default, // 内置默认组不可删除 CUSTOM_GROUP custom, // 自定义组付费计划支持 } export enum USER_ROLE { END_USER end-user, ADMIN admin, BUILDER builder, } export enum ResourceType { APP app, DATA_SOURCE data_source, WORKFLOWS workflow, FOLDER folder, MODULE module, WORKFLOW_FOLDER workflow_folder, MODULE_FOLDER module_folder, }从源码结构看ToolJet 的权限管控资源已经从文档中提到的Apps、Folders、Workspace Variables扩展到了Data Sources、Workflows、Modules及其各自的文件夹维度权限粒度也从Create/Update/Delete演进为更细的canEdit、canView、canConfigure、canUse等操作位。二、内置默认组All Users 与 Admin每个 ToolJet 工作区在创建时都会自动生成两个默认用户组它们由服务端的createDefaultGroups逻辑在组织初始化时批量创建见 util.service.ts1. All Users所有用户包含工作区内的全部用户与管理员新用户被邀请时默认加入此组组的成员列表不可手动增删因为它的含义就是所有人管理员可以编辑该组的权限从而全局性地影响所有用户的能力。2. Admin管理员默认包含所有管理员管理员可以继续添加或移除组内成员该组对工作区内的所有 App 默认拥有Edit权限并具备创建/删除 App、创建文件夹等完整能力组的权限开关默认全开且修改被禁用——它代表的是工作区最高权限集合。这两组的权限基线定义在 DEFAULT_GROUP_PERMISSIONS 中。例如管理员组的核心权限位如下ADMIN: { name: USER_ROLE.ADMIN, type: GROUP_PERMISSIONS_TYPE.DEFAULT, appCreate: true, appDelete: true, folderCreate: true, folderDelete: true, orgConstantCRUD: true, // 工作区常量Workspace Constants增删改 tjdbCRUD: true, // ToolJet Database 增删改 dataSourceCreate: true, dataSourceDelete: true, isBuilderLevel: true, // 判定为构建者级别可访问开发/暂存环境 appPromote: true, // 应用提级Promote appRelease: true, // 应用发布Release }而End-user终端用户角色的所有布尔权限位均为false仅能消费已发布Released的内容。此外源码中的HUMANIZED_USER_LIST [End-user, Builder, Admin]与USER_ROLE被用作保留字校验validateCreateGroupOperation与validateUpdateGroupOperation见 util.service.ts会拒绝使用这些名称创建或重命名自定义组防止与内置角色混淆。注意2.50.0-LTS 版本在文档层面强调两个默认组但服务端已经引入了第三个内置角色Builder构建者。可以推断在较新的版本中默认组已扩展为 End-user / Admin / Builder 三组createDefaultGroups正是遍历USER_ROLE枚举逐个创建的。若你使用的版本界面仍只显示两个组请以实际版本为准。三、自定义组与细粒度权限设置默认组的权限是一刀切的而自定义组是 ToolJet 实现最小权限原则Principle of Least Privilege的核心工具。官方文档给出了一个典型场景创建一个名为Finance Team的自定义组仅授予其访问财务相关 App 和工作区变量的权限。邀请新用户时直接将其分配到该组确保他们只能访问完成本职工作所需的最小资源集合。3.1 创建自定义组付费计划专属根据 manage-users-groups.md 的说明创建新组的选项仅在付费计划中可用。操作步骤进入仪表盘左侧边栏的Workspace Settings→Groups页面点击Create new group按钮输入组名称点击Create Group创建完成后为该组配置Apps、Users、Permissions、Data Sources四个维度的内容。这一付费门控在源码中同样有体现getAllGroupByOrganization在许可证未启用customGroupsEnabled功能时会把所有自定义组标记为disabled见 util.service.ts而addUsersToGroup、updateGroup也会在许可证无效时对自定义组抛出ForbiddenException。3.2 组的四个配置区块每一个用户组在界面上都有四个配置区域对应着不同资源维度的授权区块可配置内容谁能配置Apps为组添加/移除任意数量的 App并为每个 App 单独设置View或Edit权限Admins、Super AdminsUsers为组添加/移除任意数量的用户Admins、Super AdminsPermissions细粒度权限Create/Delete Apps、Create/Update/Delete Folders、Create/Update/Delete 工作区常量、Create/Delete Data SourcesAdmins、Super AdminsData Sources定义该组用户可**查看View或编辑Edit**哪些数据源仅 Admins、Super Admins3.3 App 级权限View 与 Edit在Apps区块中同一个组内的不同 App 可以拥有不同的权限级别View仅能查看/使用该 App运行已发布版本Edit可以打开并修改该 App 的定义。在服务端这一关系由多对多关联表承载。仓库中 apps_group_permissions.entity.ts 保存组-应用的授权记录app.entity.ts、app_base.entity.ts 等实体则定义了应用本身的属性。而真正决定当前用户能否执行某操作的是位于 server/src/modules/casl/casl-ability.factory.ts 的 CASL 能力工厂——它根据用户所属组的权限位动态构建能力集合再由 ability/guard.ts 等守卫在请求进入控制器前完成鉴权。3.4 资源级默认授权矩阵在创建默认组时除了布尔型权限位ToolJet 还会为每个组生成资源级granular默认权限定义在 DEFAULT_RESOURCE_PERMISSIONS 中。以 App 资源为例三个角色的默认差异如下权限项AdminBuilderEnd-usercanEdittruetruefalsecanViewfalseEdit 隐含 ViewfalsetruecanAccessDevelopmenttruetruefalsecanAccessStagingtruetruefalsecanAccessProductiontruefalsefalsecanAccessReleasedtruetruetrue可以看到一个关键设计End-user 默认只能访问 Released已发布版本的 App无法触碰开发Development与暂存Staging环境而 Builder 虽然可以编辑应用但默认无权访问生产环境——这是为了防止未经验证的应用改动直接影响线上数据。文件夹Folder维度同样有三档选择canEditFolder编辑文件夹、canEditApps编辑其中应用、canViewApps仅查看其中应用且只保存被选中档位的布尔值隐含的低档权限在运行时推导见 granular_permissions.ts 中各资源的显示名称映射。四、用户管理的完整操作闭环权限体系的落地离不开用户生命周期管理。以下操作均在Workspace Settings → Users页面完成4.1 邀请用户Invite点击 Users 页面右上角的Add users按钮在右侧抽屉中选择Invite with email标签页填写Full Name、Email address并从下拉框中选择要分配的用户组All Users为默认组也可选择新建的自定义组点击Invite Users后系统会向该邮箱发送包含Invite Link的邀请邮件用户通过链接加入工作区后状态由Invited变为Active可点击 Invited 状态旁的Copy link复制邀请链接也可通过Bulk Invite标签页上传 CSV 模板批量邀请用户。4.2 编辑用户与归档/恢复Edit user details通过用户行右侧的 kebab 菜单进入可在抽屉中为成员添加或移除所属组修改后点击Update保存Archive归档用户将禁用其对该工作区的访问状态变为Archived。注意被归档的用户仍可被邀请到其他工作区除非在实例级Settings页面Super Admin中被实例级归档Unarchive恢复归档用户的访问权。若用户曾在实例级被归档那么从任一工作区恢复其状态时会连带解除实例级归档恢复后状态变为Invited需要重新通过邮件链接加入。在服务端归档相关的状态常量定义于 server/src/modules/users/constants/lifecycle.tsUSER_STATUS与WORKSPACE_USER_STATUS而addUsersToGroup在添加成员时会显式排除已归档用户见 util.service.ts从数据层保证了归档用户无法被重新加入组。4.3 删除自定义组在Groups页面点击组行右侧的Delete确认后点击Yes即可删除自定义组。源码层面deleteGroup会拒绝删除type GROUP_PERMISSIONS_TYPE.DEFAULT的默认组抛出DEFAULT_GROUP_UPDATE_NOT_ALLOWED错误见 util.service.ts——默认组永远无法被删除这是数据完整性的硬约束。五、安全实践最小权限与公开访问综合官方文档与源码在 ToolJet 中落实安全访问控制的推荐路径是先规划再建组按业务职能Finance、Support、Engineering而非按个人建立自定义组一个用户可属于多个组权限取并集用组隔离资源为每个组精确配置 Apps、Data Sources、工作区常量的 View/Edit 权限遵循最小权限原则邀请即授权新用户邀请流程中直接分配对应组避免先全量放行、后逐个回收审慎处理公开访问文档指出你还可以将 App设为公开Public使其无需登录即可访问——这适用于对外展示类应用但应只针对只读场景切勿将含敏感数据的内部应用公开借助审计日志回溯工作区内 Admin、Super Admin 或任何用户的全部操作都会被记录在Audit logs中包括用户与组的管理行为。当发生权限事故时审计日志是定位谁在何时改了什么的第一手证据。相关实现在 server/src/modules/group-permissions/util.service.ts 中可见——每次更新、删除组或移除成员时都会通过RequestContext.setLocals写入包含userId、organizationId、resourceId、resourceName的审计上下文。六、总结ToolJet 的权限体系是一个以用户组为授权单元、以资源操作位为粒度的 RBAC 实现内置的 All Users 与 Admin 组提供了开箱即用的基线付费计划下的自定义组则允许工作区按业务边界精细切分权限。从 constants/index.ts 中的默认权限矩阵到 util.service.ts 中的组生命周期管理再到 CASL 能力工厂的运行时鉴权整条链路在服务端都有清晰的代码支撑。掌握了组即权限集合、用户多组取并集、资源分维授权、默认组不可删、终端用户仅见已发布内容这五个要点你就能在自己的工作区中构建一套既灵活又安全的访问控制方案。【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ToolJet 权限体系深入解析：基于用户组（User Groups）的 RBAC 访问控制实战指南
ToolJet 权限体系深入解析基于用户组User Groups的 RBAC 访问控制实战指南【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet在 ToolJet 中权限管理以基于角色的访问控制RBAC为核心管理员负责邀请用户进入工作区Workspace并将他们分配到特定的用户组Groups每个组都绑定一组权限Permissions用来决定成员对 App、文件夹、工作区变量等资源的访问级别。本文将以 ToolJet 2.50.0-LTS 版本的官方文档 permissions.md 为主线结合仓库中server/src/modules/group-permissions的源码实现系统讲解默认组、自定义组、细粒度权限以及实际运维中的落地步骤帮助你像管理员一样精确控制谁能在你的 ToolJet 工作区里做什么。一、RBAC 核心模型资源、组与权限的关系在 ToolJet 中整个权限体系由三类基本元素构成理解了这三者的关系就理解了权限系统的全貌元素说明Users用户工作区成员每个用户关联一个邮箱可以被加入一个或多个组Groups用户组权限的载体。默认存在All Users与Admin两个组此外可创建如 Support、Engineering 等自定义组Resources资源管理员可以设置权限的对象包括Apps应用、Folders文件夹与Workspace Variables工作区变量Permissions权限施加在资源上的操作能力核心是Create创建、Update更新、Delete删除在 App 级别则细化为View查看与Edit编辑这一模型在服务端源码中有着精确的对应。在 server/src/modules/group-permissions/constants/index.ts 中定义了组的类型与内置角色export enum GROUP_PERMISSIONS_TYPE { DEFAULT default, // 内置默认组不可删除 CUSTOM_GROUP custom, // 自定义组付费计划支持 } export enum USER_ROLE { END_USER end-user, ADMIN admin, BUILDER builder, } export enum ResourceType { APP app, DATA_SOURCE data_source, WORKFLOWS workflow, FOLDER folder, MODULE module, WORKFLOW_FOLDER workflow_folder, MODULE_FOLDER module_folder, }从源码结构看ToolJet 的权限管控资源已经从文档中提到的Apps、Folders、Workspace Variables扩展到了Data Sources、Workflows、Modules及其各自的文件夹维度权限粒度也从Create/Update/Delete演进为更细的canEdit、canView、canConfigure、canUse等操作位。二、内置默认组All Users 与 Admin每个 ToolJet 工作区在创建时都会自动生成两个默认用户组它们由服务端的createDefaultGroups逻辑在组织初始化时批量创建见 util.service.ts1. All Users所有用户包含工作区内的全部用户与管理员新用户被邀请时默认加入此组组的成员列表不可手动增删因为它的含义就是所有人管理员可以编辑该组的权限从而全局性地影响所有用户的能力。2. Admin管理员默认包含所有管理员管理员可以继续添加或移除组内成员该组对工作区内的所有 App 默认拥有Edit权限并具备创建/删除 App、创建文件夹等完整能力组的权限开关默认全开且修改被禁用——它代表的是工作区最高权限集合。这两组的权限基线定义在 DEFAULT_GROUP_PERMISSIONS 中。例如管理员组的核心权限位如下ADMIN: { name: USER_ROLE.ADMIN, type: GROUP_PERMISSIONS_TYPE.DEFAULT, appCreate: true, appDelete: true, folderCreate: true, folderDelete: true, orgConstantCRUD: true, // 工作区常量Workspace Constants增删改 tjdbCRUD: true, // ToolJet Database 增删改 dataSourceCreate: true, dataSourceDelete: true, isBuilderLevel: true, // 判定为构建者级别可访问开发/暂存环境 appPromote: true, // 应用提级Promote appRelease: true, // 应用发布Release }而End-user终端用户角色的所有布尔权限位均为false仅能消费已发布Released的内容。此外源码中的HUMANIZED_USER_LIST [End-user, Builder, Admin]与USER_ROLE被用作保留字校验validateCreateGroupOperation与validateUpdateGroupOperation见 util.service.ts会拒绝使用这些名称创建或重命名自定义组防止与内置角色混淆。注意2.50.0-LTS 版本在文档层面强调两个默认组但服务端已经引入了第三个内置角色Builder构建者。可以推断在较新的版本中默认组已扩展为 End-user / Admin / Builder 三组createDefaultGroups正是遍历USER_ROLE枚举逐个创建的。若你使用的版本界面仍只显示两个组请以实际版本为准。三、自定义组与细粒度权限设置默认组的权限是一刀切的而自定义组是 ToolJet 实现最小权限原则Principle of Least Privilege的核心工具。官方文档给出了一个典型场景创建一个名为Finance Team的自定义组仅授予其访问财务相关 App 和工作区变量的权限。邀请新用户时直接将其分配到该组确保他们只能访问完成本职工作所需的最小资源集合。3.1 创建自定义组付费计划专属根据 manage-users-groups.md 的说明创建新组的选项仅在付费计划中可用。操作步骤进入仪表盘左侧边栏的Workspace Settings→Groups页面点击Create new group按钮输入组名称点击Create Group创建完成后为该组配置Apps、Users、Permissions、Data Sources四个维度的内容。这一付费门控在源码中同样有体现getAllGroupByOrganization在许可证未启用customGroupsEnabled功能时会把所有自定义组标记为disabled见 util.service.ts而addUsersToGroup、updateGroup也会在许可证无效时对自定义组抛出ForbiddenException。3.2 组的四个配置区块每一个用户组在界面上都有四个配置区域对应着不同资源维度的授权区块可配置内容谁能配置Apps为组添加/移除任意数量的 App并为每个 App 单独设置View或Edit权限Admins、Super AdminsUsers为组添加/移除任意数量的用户Admins、Super AdminsPermissions细粒度权限Create/Delete Apps、Create/Update/Delete Folders、Create/Update/Delete 工作区常量、Create/Delete Data SourcesAdmins、Super AdminsData Sources定义该组用户可**查看View或编辑Edit**哪些数据源仅 Admins、Super Admins3.3 App 级权限View 与 Edit在Apps区块中同一个组内的不同 App 可以拥有不同的权限级别View仅能查看/使用该 App运行已发布版本Edit可以打开并修改该 App 的定义。在服务端这一关系由多对多关联表承载。仓库中 apps_group_permissions.entity.ts 保存组-应用的授权记录app.entity.ts、app_base.entity.ts 等实体则定义了应用本身的属性。而真正决定当前用户能否执行某操作的是位于 server/src/modules/casl/casl-ability.factory.ts 的 CASL 能力工厂——它根据用户所属组的权限位动态构建能力集合再由 ability/guard.ts 等守卫在请求进入控制器前完成鉴权。3.4 资源级默认授权矩阵在创建默认组时除了布尔型权限位ToolJet 还会为每个组生成资源级granular默认权限定义在 DEFAULT_RESOURCE_PERMISSIONS 中。以 App 资源为例三个角色的默认差异如下权限项AdminBuilderEnd-usercanEdittruetruefalsecanViewfalseEdit 隐含 ViewfalsetruecanAccessDevelopmenttruetruefalsecanAccessStagingtruetruefalsecanAccessProductiontruefalsefalsecanAccessReleasedtruetruetrue可以看到一个关键设计End-user 默认只能访问 Released已发布版本的 App无法触碰开发Development与暂存Staging环境而 Builder 虽然可以编辑应用但默认无权访问生产环境——这是为了防止未经验证的应用改动直接影响线上数据。文件夹Folder维度同样有三档选择canEditFolder编辑文件夹、canEditApps编辑其中应用、canViewApps仅查看其中应用且只保存被选中档位的布尔值隐含的低档权限在运行时推导见 granular_permissions.ts 中各资源的显示名称映射。四、用户管理的完整操作闭环权限体系的落地离不开用户生命周期管理。以下操作均在Workspace Settings → Users页面完成4.1 邀请用户Invite点击 Users 页面右上角的Add users按钮在右侧抽屉中选择Invite with email标签页填写Full Name、Email address并从下拉框中选择要分配的用户组All Users为默认组也可选择新建的自定义组点击Invite Users后系统会向该邮箱发送包含Invite Link的邀请邮件用户通过链接加入工作区后状态由Invited变为Active可点击 Invited 状态旁的Copy link复制邀请链接也可通过Bulk Invite标签页上传 CSV 模板批量邀请用户。4.2 编辑用户与归档/恢复Edit user details通过用户行右侧的 kebab 菜单进入可在抽屉中为成员添加或移除所属组修改后点击Update保存Archive归档用户将禁用其对该工作区的访问状态变为Archived。注意被归档的用户仍可被邀请到其他工作区除非在实例级Settings页面Super Admin中被实例级归档Unarchive恢复归档用户的访问权。若用户曾在实例级被归档那么从任一工作区恢复其状态时会连带解除实例级归档恢复后状态变为Invited需要重新通过邮件链接加入。在服务端归档相关的状态常量定义于 server/src/modules/users/constants/lifecycle.tsUSER_STATUS与WORKSPACE_USER_STATUS而addUsersToGroup在添加成员时会显式排除已归档用户见 util.service.ts从数据层保证了归档用户无法被重新加入组。4.3 删除自定义组在Groups页面点击组行右侧的Delete确认后点击Yes即可删除自定义组。源码层面deleteGroup会拒绝删除type GROUP_PERMISSIONS_TYPE.DEFAULT的默认组抛出DEFAULT_GROUP_UPDATE_NOT_ALLOWED错误见 util.service.ts——默认组永远无法被删除这是数据完整性的硬约束。五、安全实践最小权限与公开访问综合官方文档与源码在 ToolJet 中落实安全访问控制的推荐路径是先规划再建组按业务职能Finance、Support、Engineering而非按个人建立自定义组一个用户可属于多个组权限取并集用组隔离资源为每个组精确配置 Apps、Data Sources、工作区常量的 View/Edit 权限遵循最小权限原则邀请即授权新用户邀请流程中直接分配对应组避免先全量放行、后逐个回收审慎处理公开访问文档指出你还可以将 App设为公开Public使其无需登录即可访问——这适用于对外展示类应用但应只针对只读场景切勿将含敏感数据的内部应用公开借助审计日志回溯工作区内 Admin、Super Admin 或任何用户的全部操作都会被记录在Audit logs中包括用户与组的管理行为。当发生权限事故时审计日志是定位谁在何时改了什么的第一手证据。相关实现在 server/src/modules/group-permissions/util.service.ts 中可见——每次更新、删除组或移除成员时都会通过RequestContext.setLocals写入包含userId、organizationId、resourceId、resourceName的审计上下文。六、总结ToolJet 的权限体系是一个以用户组为授权单元、以资源操作位为粒度的 RBAC 实现内置的 All Users 与 Admin 组提供了开箱即用的基线付费计划下的自定义组则允许工作区按业务边界精细切分权限。从 constants/index.ts 中的默认权限矩阵到 util.service.ts 中的组生命周期管理再到 CASL 能力工厂的运行时鉴权整条链路在服务端都有清晰的代码支撑。掌握了组即权限集合、用户多组取并集、资源分维授权、默认组不可删、终端用户仅见已发布内容这五个要点你就能在自己的工作区中构建一套既灵活又安全的访问控制方案。【免费下载链接】ToolJetOpen-source foundation of ToolJet AI - the enterprise app generation platform for internal tools, dashboards, business applications, workflows and AI agents. Build visually, from a prompt, or from Claude Code, Codex and Cursor over MCP 项目地址: https://gitcode.com/GitHub_Trending/to/ToolJet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考