ToolJet RBAC 用户组权限深度解析3 个默认角色、2 张核心表、4 条红线【免费下载链接】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 后你多半会撞见这个场景财务同事登录后在应用列表里看到了 HR 的薪酬统计——应用是发布过的但这不该是她能碰的东西。问题出在 ToolJet 的 RBACRole-Based Access Control基于角色的访问控制权限模型上用户不直接挂权限而是先放进用户组Group组再携带两层权限——组级开关和面向具体资源的细粒度授权Granular Permissions。下文直接拆服务端group-permissions模块源码帮你在自建实例上把权限配到财务只摸财务应用的精度。一表看懂 ToolJet 权限三层结构权限体系一共三层每层都有明确的数据库载体层级载体职责组织 Organizationorganization_id外键隔离边界所有组与权限记录都挂在组织下用户组 Grouppermission_groups表用户到权限的中间层成员由GroupUsers关联表维护权限位 Permissions组行布尔位 granular_permissions表组级回答能不能做某类事资源级回答能碰哪些具体应用/文件夹把组织理解成一家公司、组理解成部门岗位卡、细粒度授权理解成具体项目的门禁卡这个结构就直观了——落回字段门禁卡就是permission_groups行下挂的groupGranularPermissions一对多关联而公司编号就是organization_id。默认三角色在资源层面的权限矩阵✅ / ❌ / 可配置如下与官方文档 user-roles.md 的描述一致资源动作AdminBuilderEnd-user应用创建/更新/删除✅可配置❌应用查看✅可配置可配置数据源创建/更新/删除✅可配置❌文件夹创建/更新/删除✅可配置❌工作空间常量创建/更新/删除✅可配置❌可配置三个字是重点Builder 和 End-user 的格子不是写死的而是可以被细粒度授权改写的。✅权限数据落在哪permission_groups 与 granular_permissions全部权限数据落在两张表里字段职责如下。permission_groupsgroup_permissions.entity.ts字段组职责organization_id/name/type归属组织组名三个内置角色就叫admin/builder/end-userdefault或custom18 个布尔位appCreate/appDelete/folderCreate/folderDelete/workflowCreate/workflowDelete/moduleCreate/moduleDelete/workflowFolderCreate等创建删除位加上orgConstantCRUD工作空间常量增删改、tjdbCRUD内置数据库操作、dataSourceCreate/dataSourceDelete、appPromote/appRelease多环境晋级与发布关联groupUsers成员删组级联删、groupGranularPermissions细粒度授权删组级联删、PageUser/QueryUser/ComponentUser页面、查询、组件级授权同样以组为单位granular_permissionsgranular_permissions.entity.ts字段职责group_idname归属哪个组权限名有唯一约束撞名直接落库失败type这条授权针对哪类资源取自ResourceType枚举isAll默认true表示覆盖该类资源全集无需枚举置false后通过GroupApps/GroupFolders等中间表逐个关联具体资源 ID三个 OneToOne 子表AppsGroupPermissions应用动作 环境位、DataSourcesGroupPermissions数据源动作、FoldersGroupPermissions文件夹动作全部onDelete: CASCADE——删掉授权主记录动作位和资源关联自动清空不会留下孤儿授权实体核心骨架Entity({ name: granular_permissions }) export class GranularPermissions extends BaseEntity { id: string; // uuid 主键 groupId: string; // 归属组 name: string; // 权限名唯一约束 type: ResourceType; // app / data_source / workflow / folder / module / ... isAll: boolean; // true 该类资源全集授权 appsGroupPermissions: AppsGroupPermissions; // OneToOne, 删组授权级联删 dataSourcesGroupPermission: DataSourcesGroupPermissions; // OneToOne, 级联 foldersGroupPermissions: FoldersGroupPermissions; // OneToOne, 级联 }级联删除是运维上的大省心点解散一个组、或删掉某条授权所有子记录自动消失不用手动清表。⚙️3 个默认角色与自定义组Admin 和 Builder 差在哪三个内置角色由 constants/index.ts 的USER_ROLE枚举定义end-user、builder、admin。组的type字段则区分default内置三角色组每个组织自动拥有和custom自定义组管理员可任意命名、独立配权限位、自由授权资源可包含构建级权限是官方推荐的多团队隔离手段详见 custom-groups.md。这里有个容易踩反直觉的点很多人以为 Admin 和 Builder 的差别在组级权限位上但翻DEFAULT_GROUP_PERMISSIONS源码会发现两个角色的 18 个组级布尔位完全相同全部为true。真正的差异全在下一层资源级授权维度AdminBuilderEnd-user组级 18 个布尔位全true全true与 Admin 逐位相同全false应用环境访问Dev / Staging / Prod / Released 全开Dev / Staging / Released生产关闭仅 Released文件夹档位Edit folderEdit folderView apps也就是说Builder 比 Admin 少什么这个问题的答案只有一个字段canAccessProduction: false。想要更细的差别只能用 custom 组自己拼。细粒度授权从能不能到动哪些组级权限位只回答能不能动哪些具体资源由granular_permissions承担。type字段覆盖 7 类资源app、data_source、workflow、folder、module、workflow_folder、module_folder。isAll 的两种授权模式模式行为isAll true覆盖该类资源全集创建时后端会强制清空resourcesToAdd全集授权不接收资源枚举isAll false通过GroupApps/GroupFolders中间表逐个挂资源 ID更新时支持resourcesToAdd/resourcesToDelete增量维护动作位规则按资源类型分三套资源类型动作位规则应用 / 工作流 / 模块canEdit/canView 4 个环境位canEdit与canView互斥置canEdittrue强制canViewfalse反之亦然环境位canAccessDevelopment/canAccessStaging/canAccessProduction/canAccessReleased独立控制环境访问数据源canConfigure/canUse配置管理 vs 仅使用两档文件夹含 workflow_folder、module_foldercanEditFolder/canEditApps/canViewApps单选层级只置选中档为true隐含权限在运行时推导互斥逻辑在更新路径里就两行硬编码if (actions.canEdit) actions.canView false; else if (actions.canView) actions.canEdit false;环境位差异是三角色拉开身位的关键Admin 四位全开含生产Builder 止步 StagingcanAccessProductionfalse但保留canAccessReleasedEnd-user 只有canAccessReleasedtrue三个构建环境位全关。前端配置界面长这样创建时按type分派落库文件夹三类含workflow_folder、module_folder统一走文件夹逻辑其余走应用级逻辑。✅四条系统红线违反时会有什么表现安全约束集中在 granular-permissions.util.service.ts四条红线全部强制执行#红线拒绝条件违反时的表现1Admin 组禁改对name admin的组创建或更新细粒度授权直接抛BadRequestException400提示 Admin 默认组不支持细粒度权限配置——防管理员误操作失权2End-user 禁构建级应用/工作流canEdittrue拒绝Module 更严连canViewBuild-with也拒模块永不分配给 end-user数据源canConfigure或canUse拒绝文件夹canEditFolder/canEditApps拒绝module_folder 则任何授权都拒400 错误type: USER_ROLE_CHANGE_ADD_PERMISSIONSdata里附带组内所有 end-user 的邮箱列表方便定位要调角色的用户3多环境许可证门控给组开canAccessDevelopment/Staging/Production时先查组织是否持有MULTI_ENVIRONMENT许可条款licenseTermsService.getLicenseTerms无该条款且组内有 end-user 时走红线 2 的同一套拒绝逻辑——多环境隔离能力本身就是许可证门控的4allowRoleChange 自动升级更新授权时判定为构建级更新canEdittrue或 Module且组内存在 end-user请求不带allowRoleChange抛 405MethodNotAllowedExceptiontype: USER_ROLE_CHANGE带了调用changeEndUserToEditor把组内 end-user批量升级为 builder红线 4 解释了前端的变更组权限后弹出角色变更确认交互弹窗问的不是要不要加权限而是要不要顺带把这批 end-user 升成 builder。❌实战给财务团队配一套权限目标Finance Team 只能看财务应用和工作空间常量碰不了生产环境也碰不了 HR 报表。操作顺序是固定的——先建组 → 再配权限 → 最后加人因为 end-user 红线扫描以组内是否有人为前提先加人再配权限大概率被红线 2 拦下。建组Workspace settings → Groups → 新建Finance Teamtypecustom。后端create()落permission_groups并通过RequestContext记录GROUP_PERMISSION_CREATE审计事件见 service.ts。配组级权限位appCreate/appDelete/dataSourceCreate等建删位保持false若财务需要维护工作空间常量单独打开orgConstantCRUD。加细粒度授权建一条typeapp、isAllfalse的授权动作位canViewtruecanAccessReleasedtrue不要开canEdit和构建环境位resourcesToAdd只列财务应用 ID。想连数据源一起限定就再挂一条typedata_source、canUsetrue的授权。拉入成员addGroupUsers在事务内批量写GroupUsers随后licenseUserService.validateUser校验组织用户配额许可证约束最后记USER_ADD_TO_GROUP审计。如果已有配置好的组想快速复制用duplicateGroup可选addPermission复制权限位、addUsers同步成员、addApps复制应用级细粒度授权完成后同样过许可证校验并记GROUP_PERMISSION_DUPLICATE审计。⚙️FAQToolJet 权限的 3 个常见疑问Q1为什么 End-user 打不开 staging 版本默认END_USER授权里三个构建环境位全为false只有canAccessReleasedtrue。而且你想手动打开时还会被双重拦截先查组织MULTI_ENVIRONMENT许可条款自建基础版没有的话直接走 end-user 拒绝逻辑。要放行先升级许可证条款再改对应应用的授权。Q2角色变更确认弹窗是从哪来的来自更新授权的校验路径后端validateResourceAction发现是构建级更新且组内有 end-user 时若请求allowRoleChangefalse抛 405type: USER_ROLE_CHANGE附带端用户邮箱前端收到后弹确认框用户确认后带allowRoleChangetrue重发后端执行changeEndUserToEditor批量升级。弹窗的本质是让你确认这批 end-user 会变成 builder。Q3应用设为 public 之后权限还生效吗生效。public 只改变访问入口——允许未登录用户查看 released 版本相当于把 Released 环境对匿名开放。但已登录用户依然走用户组体系组级权限位、canEdit/canView、环境访问位照旧校验。公开一个应用不会稀释任何组的编辑权限或构建环境权限。收尾一句话 权限设计自查清单ToolJet 权限模型 组织定边界组做授权单位组级权限位管能不能granular_permissions 管动哪些四条红线由 util 服务在写入时统一拦截。落地前自查三条顺序自检是否按建组 → 配权限 → 加人操作先加人再配构建级权限end-user 红线必拦。许可证自检规划环境访问方案前确认组织持有MULTI_ENVIRONMENT条款——没有它end-user 组永远只到 Released。边界自检Admin 组的细粒度授权界面是封死的别试图绕过需要收敛管理员权限时答案在角色分配和自定义组不在授权接口。【免费下载链接】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 RBAC 用户组权限深度解析：3 个默认角色、2 张核心表、4 条红线
ToolJet RBAC 用户组权限深度解析3 个默认角色、2 张核心表、4 条红线【免费下载链接】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 后你多半会撞见这个场景财务同事登录后在应用列表里看到了 HR 的薪酬统计——应用是发布过的但这不该是她能碰的东西。问题出在 ToolJet 的 RBACRole-Based Access Control基于角色的访问控制权限模型上用户不直接挂权限而是先放进用户组Group组再携带两层权限——组级开关和面向具体资源的细粒度授权Granular Permissions。下文直接拆服务端group-permissions模块源码帮你在自建实例上把权限配到财务只摸财务应用的精度。一表看懂 ToolJet 权限三层结构权限体系一共三层每层都有明确的数据库载体层级载体职责组织 Organizationorganization_id外键隔离边界所有组与权限记录都挂在组织下用户组 Grouppermission_groups表用户到权限的中间层成员由GroupUsers关联表维护权限位 Permissions组行布尔位 granular_permissions表组级回答能不能做某类事资源级回答能碰哪些具体应用/文件夹把组织理解成一家公司、组理解成部门岗位卡、细粒度授权理解成具体项目的门禁卡这个结构就直观了——落回字段门禁卡就是permission_groups行下挂的groupGranularPermissions一对多关联而公司编号就是organization_id。默认三角色在资源层面的权限矩阵✅ / ❌ / 可配置如下与官方文档 user-roles.md 的描述一致资源动作AdminBuilderEnd-user应用创建/更新/删除✅可配置❌应用查看✅可配置可配置数据源创建/更新/删除✅可配置❌文件夹创建/更新/删除✅可配置❌工作空间常量创建/更新/删除✅可配置❌可配置三个字是重点Builder 和 End-user 的格子不是写死的而是可以被细粒度授权改写的。✅权限数据落在哪permission_groups 与 granular_permissions全部权限数据落在两张表里字段职责如下。permission_groupsgroup_permissions.entity.ts字段组职责organization_id/name/type归属组织组名三个内置角色就叫admin/builder/end-userdefault或custom18 个布尔位appCreate/appDelete/folderCreate/folderDelete/workflowCreate/workflowDelete/moduleCreate/moduleDelete/workflowFolderCreate等创建删除位加上orgConstantCRUD工作空间常量增删改、tjdbCRUD内置数据库操作、dataSourceCreate/dataSourceDelete、appPromote/appRelease多环境晋级与发布关联groupUsers成员删组级联删、groupGranularPermissions细粒度授权删组级联删、PageUser/QueryUser/ComponentUser页面、查询、组件级授权同样以组为单位granular_permissionsgranular_permissions.entity.ts字段职责group_idname归属哪个组权限名有唯一约束撞名直接落库失败type这条授权针对哪类资源取自ResourceType枚举isAll默认true表示覆盖该类资源全集无需枚举置false后通过GroupApps/GroupFolders等中间表逐个关联具体资源 ID三个 OneToOne 子表AppsGroupPermissions应用动作 环境位、DataSourcesGroupPermissions数据源动作、FoldersGroupPermissions文件夹动作全部onDelete: CASCADE——删掉授权主记录动作位和资源关联自动清空不会留下孤儿授权实体核心骨架Entity({ name: granular_permissions }) export class GranularPermissions extends BaseEntity { id: string; // uuid 主键 groupId: string; // 归属组 name: string; // 权限名唯一约束 type: ResourceType; // app / data_source / workflow / folder / module / ... isAll: boolean; // true 该类资源全集授权 appsGroupPermissions: AppsGroupPermissions; // OneToOne, 删组授权级联删 dataSourcesGroupPermission: DataSourcesGroupPermissions; // OneToOne, 级联 foldersGroupPermissions: FoldersGroupPermissions; // OneToOne, 级联 }级联删除是运维上的大省心点解散一个组、或删掉某条授权所有子记录自动消失不用手动清表。⚙️3 个默认角色与自定义组Admin 和 Builder 差在哪三个内置角色由 constants/index.ts 的USER_ROLE枚举定义end-user、builder、admin。组的type字段则区分default内置三角色组每个组织自动拥有和custom自定义组管理员可任意命名、独立配权限位、自由授权资源可包含构建级权限是官方推荐的多团队隔离手段详见 custom-groups.md。这里有个容易踩反直觉的点很多人以为 Admin 和 Builder 的差别在组级权限位上但翻DEFAULT_GROUP_PERMISSIONS源码会发现两个角色的 18 个组级布尔位完全相同全部为true。真正的差异全在下一层资源级授权维度AdminBuilderEnd-user组级 18 个布尔位全true全true与 Admin 逐位相同全false应用环境访问Dev / Staging / Prod / Released 全开Dev / Staging / Released生产关闭仅 Released文件夹档位Edit folderEdit folderView apps也就是说Builder 比 Admin 少什么这个问题的答案只有一个字段canAccessProduction: false。想要更细的差别只能用 custom 组自己拼。细粒度授权从能不能到动哪些组级权限位只回答能不能动哪些具体资源由granular_permissions承担。type字段覆盖 7 类资源app、data_source、workflow、folder、module、workflow_folder、module_folder。isAll 的两种授权模式模式行为isAll true覆盖该类资源全集创建时后端会强制清空resourcesToAdd全集授权不接收资源枚举isAll false通过GroupApps/GroupFolders中间表逐个挂资源 ID更新时支持resourcesToAdd/resourcesToDelete增量维护动作位规则按资源类型分三套资源类型动作位规则应用 / 工作流 / 模块canEdit/canView 4 个环境位canEdit与canView互斥置canEdittrue强制canViewfalse反之亦然环境位canAccessDevelopment/canAccessStaging/canAccessProduction/canAccessReleased独立控制环境访问数据源canConfigure/canUse配置管理 vs 仅使用两档文件夹含 workflow_folder、module_foldercanEditFolder/canEditApps/canViewApps单选层级只置选中档为true隐含权限在运行时推导互斥逻辑在更新路径里就两行硬编码if (actions.canEdit) actions.canView false; else if (actions.canView) actions.canEdit false;环境位差异是三角色拉开身位的关键Admin 四位全开含生产Builder 止步 StagingcanAccessProductionfalse但保留canAccessReleasedEnd-user 只有canAccessReleasedtrue三个构建环境位全关。前端配置界面长这样创建时按type分派落库文件夹三类含workflow_folder、module_folder统一走文件夹逻辑其余走应用级逻辑。✅四条系统红线违反时会有什么表现安全约束集中在 granular-permissions.util.service.ts四条红线全部强制执行#红线拒绝条件违反时的表现1Admin 组禁改对name admin的组创建或更新细粒度授权直接抛BadRequestException400提示 Admin 默认组不支持细粒度权限配置——防管理员误操作失权2End-user 禁构建级应用/工作流canEdittrue拒绝Module 更严连canViewBuild-with也拒模块永不分配给 end-user数据源canConfigure或canUse拒绝文件夹canEditFolder/canEditApps拒绝module_folder 则任何授权都拒400 错误type: USER_ROLE_CHANGE_ADD_PERMISSIONSdata里附带组内所有 end-user 的邮箱列表方便定位要调角色的用户3多环境许可证门控给组开canAccessDevelopment/Staging/Production时先查组织是否持有MULTI_ENVIRONMENT许可条款licenseTermsService.getLicenseTerms无该条款且组内有 end-user 时走红线 2 的同一套拒绝逻辑——多环境隔离能力本身就是许可证门控的4allowRoleChange 自动升级更新授权时判定为构建级更新canEdittrue或 Module且组内存在 end-user请求不带allowRoleChange抛 405MethodNotAllowedExceptiontype: USER_ROLE_CHANGE带了调用changeEndUserToEditor把组内 end-user批量升级为 builder红线 4 解释了前端的变更组权限后弹出角色变更确认交互弹窗问的不是要不要加权限而是要不要顺带把这批 end-user 升成 builder。❌实战给财务团队配一套权限目标Finance Team 只能看财务应用和工作空间常量碰不了生产环境也碰不了 HR 报表。操作顺序是固定的——先建组 → 再配权限 → 最后加人因为 end-user 红线扫描以组内是否有人为前提先加人再配权限大概率被红线 2 拦下。建组Workspace settings → Groups → 新建Finance Teamtypecustom。后端create()落permission_groups并通过RequestContext记录GROUP_PERMISSION_CREATE审计事件见 service.ts。配组级权限位appCreate/appDelete/dataSourceCreate等建删位保持false若财务需要维护工作空间常量单独打开orgConstantCRUD。加细粒度授权建一条typeapp、isAllfalse的授权动作位canViewtruecanAccessReleasedtrue不要开canEdit和构建环境位resourcesToAdd只列财务应用 ID。想连数据源一起限定就再挂一条typedata_source、canUsetrue的授权。拉入成员addGroupUsers在事务内批量写GroupUsers随后licenseUserService.validateUser校验组织用户配额许可证约束最后记USER_ADD_TO_GROUP审计。如果已有配置好的组想快速复制用duplicateGroup可选addPermission复制权限位、addUsers同步成员、addApps复制应用级细粒度授权完成后同样过许可证校验并记GROUP_PERMISSION_DUPLICATE审计。⚙️FAQToolJet 权限的 3 个常见疑问Q1为什么 End-user 打不开 staging 版本默认END_USER授权里三个构建环境位全为false只有canAccessReleasedtrue。而且你想手动打开时还会被双重拦截先查组织MULTI_ENVIRONMENT许可条款自建基础版没有的话直接走 end-user 拒绝逻辑。要放行先升级许可证条款再改对应应用的授权。Q2角色变更确认弹窗是从哪来的来自更新授权的校验路径后端validateResourceAction发现是构建级更新且组内有 end-user 时若请求allowRoleChangefalse抛 405type: USER_ROLE_CHANGE附带端用户邮箱前端收到后弹确认框用户确认后带allowRoleChangetrue重发后端执行changeEndUserToEditor批量升级。弹窗的本质是让你确认这批 end-user 会变成 builder。Q3应用设为 public 之后权限还生效吗生效。public 只改变访问入口——允许未登录用户查看 released 版本相当于把 Released 环境对匿名开放。但已登录用户依然走用户组体系组级权限位、canEdit/canView、环境访问位照旧校验。公开一个应用不会稀释任何组的编辑权限或构建环境权限。收尾一句话 权限设计自查清单ToolJet 权限模型 组织定边界组做授权单位组级权限位管能不能granular_permissions 管动哪些四条红线由 util 服务在写入时统一拦截。落地前自查三条顺序自检是否按建组 → 配权限 → 加人操作先加人再配构建级权限end-user 红线必拦。许可证自检规划环境访问方案前确认组织持有MULTI_ENVIRONMENT条款——没有它end-user 组永远只到 Released。边界自检Admin 组的细粒度授权界面是封死的别试图绕过需要收敛管理员权限时答案在角色分配和自定义组不在授权接口。【免费下载链接】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），仅供参考