ToolJet 用户组与 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/ToolJetToolJet 的权限管理基于角色访问控制Role-Based Access ControlRBAC构建一切授权都围绕「用户组Group」展开通过用户组内的权限位和细粒度权限Granular Permissions两个维度精确限定谁能创建应用、谁能查看数据源、谁能进入生产环境。对于自建部署或多团队协作场景理解 ToolJet 权限模型能帮助你快速设计出「按团队隔离、按环境收敛」的访问控制方案。权限全景组织、用户组与两级权限怎么层层嵌套ToolJet 的授权链条可以拆成三级每一级都对应数据库中的真实表结构组织Organization / Workspace——权限的隔离边界。所有组、权限记录、许可证条款都挂在组织之下跨组织之间天然互不可见。组的落库实体是 group_permissions.entity.ts其中organization_id字段即组织外键用户组Group——用户与权限之间的中间层。每个组织自带三个默认角色组也可以自建任意命名的自定义组。组成员关系由GroupUsers关联表维护删除组时级联清理权限Permissions——分两级组级权限位Group-level flags回答「这个组能不能做某类事」例如能否建应用、能否管理工作空间常量。它们直接以布尔列的形式存在permission_groups表上细粒度资源授权Granular Permissions回答「能做哪些具体资源」独立存储于 granular_permissions.entity.ts按应用、文件夹、数据源、工作流等类型逐条授权。组实体的核心字段大致如下完整定义见源码Entity({ name: permission_groups }) export class GroupPermissions extends BaseEntity { Column({ name: organization_id, nullable: false }) organizationId: string; Column({ name: name, nullable: false }) name: string; Column({ name: type, type: enum, enum: GROUP_PERMISSIONS_TYPE }) type: GROUP_PERMISSIONS_TYPE; // default | custom // appCreate / appDelete / folderCreate / orgConstantCRUD / // tjdbCRUD / dataSourceCreate / appPromote / appRelease ... OneToMany(() GroupUsers, (g) g.group, { onDelete: CASCADE }) groupUsers: GroupUsers[]; OneToMany(() GranularPermissions, (g) g.group, { onDelete: CASCADE }) groupGranularPermissions: GranularPermissions[]; }可以看到组既是一堆布尔开关的集合又通过一对多关系挂接了成员列表和细粒度授权。实体上还预留了PageUser、QueryUser、ComponentUser关联说明页面、查询、组件级的访问控制同样以「组」为授权单位。内置角色对比Admin、Builder、End-user 各自能做什么ToolJet 在 group-permissions 模块的 constants 中以USER_ROLE枚举定义了三个默认角色。三者能力差异可概括为下表能力维度 AdminBuilderEnd-user创建 / 删除应用appCreate / appDelete✅✅❌创建 / 删除工作流、模块及对应文件夹✅✅❌管理工作空间常量orgConstantCRUD✅✅❌操作内置数据库tjdbCRUD✅✅❌创建 / 删除数据源dataSourceCreate / dataSourceDelete✅✅❌应用晋级与发布appPromote / appRelease✅✅❌是否属于构建级isBuilderLevel✅✅❌几个要点在这一层Builder 与 Admin 的组级开关完全等价源码中两者共享同一套true配置两者的实际差别体现在下一层的资源级授权上比如环境访问范围End-user 的所有开关全部为false且isBuilderLevel: false——这是后文「End-user 硬边界」校验的根源官方角色说明可参考 user-roles.md访问控制全景见 access-control.md。组本身也分两种类型由GROUP_PERMISSIONS_TYPE枚举区分default默认组即上表三个内置角色组每个组织自动创建行为由系统约定custom自定义组管理员自由命名、自由配权限、自由加人且可以携带构建级权限是多团队隔离的主力工具。创建自定义组建组、配权限、加成员三步走在 group-permissions 的 service.ts 中组的生命周期操作都带审计日志和许可证校验对应到界面操作就是三步第一步建组并配置组级权限位调用create方法落库后写入审计日志。你可以直接勾选该组需要的能力位应用增删、常量管理、数据源管理……。注意复制组duplicateGroup支持三个开关——addPermission复制权限位、addUsers同步原组成员、addApps复制应用级细粒度授权之后仍会调用licenseUserService.validateUser校验组织用户配额许可证约束在复制时同样生效。第二步配置细粒度资源授权这一步决定「哪些具体资源」详见下一节。界面效果参考下图第三步把成员加入组addGroupUsers在事务内批量写入GroupUsers关联记录USER_ADD_TO_GROUP审计事件并做许可证校验getAddableUser则提供「谁可以被拉进这个组」的搜索列表。也就是说「建组 → 配权限 → 加人」每一步在后端都是可审计、受许可证约束的操作。更多细节见 custom-groups.md。细粒度权限配置把授权精确到具体应用、文件夹与数据源组级权限位只说「能不能」说「对谁哪个资源」的是细粒度权限。其核心实体GranularPermissions包含四个关键字段type资源类型取自ResourceType枚举共七类——app应用、data_source数据源、workflow工作流、folder文件夹、module模块、workflow_folder工作流文件夹、module_folder模块文件夹name授权名称组内唯一源码中对应唯一约束GRANULAR_PERMISSIONS_NAME_UNIQUEisAll全集标志默认true表示该类型下的全部资源都在授权范围内无需枚举置为false时通过GroupApps/GroupFolders等中间表逐个绑定具体资源 ID动作位按资源类型一对一挂接子表AppsGroupPermissions/DataSourcesGroupPermissions/FoldersGroupPermissions均为级联删除承载具体的操作权限。各默认角色的资源级默认值在DEFAULT_RESOURCE_PERMISSIONS常量中给出摘出最重要的应用资源维度角色canEdit编辑canView查看开发环境预发环境生产环境已发布版本Admin✅—✅✅✅✅Builder✅—✅✅❌✅End-user❌✅❌❌❌✅其他资源类型的动作位各有三档数据源canConfigure配置 / 管理与canUse仅使用二选一文件夹canEditFolder/canEditApps/canViewApps单选层级注释中明确说明「只把选中的那档置 true隐含权限在运行时推导」例如拥有「编辑文件夹」即运行时推导出「查看应用」能力模块Module与 End-user 完全不兼容模块永远不会分配给 end-user。对外 API 的入口与鉴权开关集中在模块的 granular-permissions.controller.ts 与 controller.ts每个操作对应FEATURE_KEY枚举中的一个键如CREATE_GRANULAR_APP_PERMISSIONS、CREATE_GRANULAR_FOLDER_PERMISSIONS、ASSIGN_GROUP_ADMIN控制器据此做功能级门禁。安全边界Admin 组不可改、End-user 硬边界与许可证门控真正的防御逻辑集中在 granular-permissions.util.service.ts有四条规则值得逐条理解。规则一Admin 默认组禁止配置细粒度权限validateGranularPermissionCreateOperation一旦发现目标组名是admin直接抛出ADMIN_DEFAULT_GROUP_GRANULAR_PERMISSIONS异常「Cannot create granular permissions of admin group」。Admin 的权限是系统全量约定的不允许通过接口收窄或扩大避免一次误操作让管理员失权。规则二End-user 组的构建级权限硬边界只要目标组内存在 end-user 成员以下授权请求会被拒绝资源类型被拒绝的动作位备注应用 / 工作流canEdit编辑属于构建级能力模块canView也一并拒绝模块永远不会分配给 end-user数据源canConfigure、canUse使用数据源本身就是构建级能力文件夹canEditFolder、canEditApps查看类不受限模块文件夹任何授权一律拒绝拒绝时返回结构化的400响应type为USER_ROLE_CHANGE_ADD_PERMISSIONSdata字段携带组内所有end-user 的邮箱——前端就是靠这个列表弹出「需要变更哪些用户角色」的提示。规则三环境访问权限与多环境许可证联动validateEnvironmentPermissions在请求涉及canAccessDevelopment/canAccessStaging/canAccessProduction时会先查询组织是否持有MULTI_ENVIRONMENT许可证条款licenseTermsService.getLicenseTerms。未持有多环境许可证的组织连给 Builder 配置环境访问都会被 end-user 拒绝逻辑拦截——多环境隔离能力本身是许可证门控的自建部署时这一点容易被忽略。规则四可选的角色自动升级allowRoleChange更新授权时若请求携带allowRoleChange: truevalidateResourceAction确认这是一次构建级变更且组内确有 end-user 时会调用roleUtilService.changeEndUserToEditor把他们批量升级为 builder否则抛出USER_ROLE_CHANGE类型的错误。前端「变更组权限后弹出角色变更确认」的交互源头就在这里。实战示例为「财务团队」设计一套最小权限方案把上面的机制串起来给一个典型的多团队场景设计权限。目标财务团队只接触财务相关应用和工作空间常量不碰生产环境也不具备构建能力。建组创建一个自定义组Finance Teamtype: custom只勾选orgConstantCRUD: true其余应用 / 数据源 / 文件夹类能力位全部保持false配细粒度授权应用资源isAll falseresourcesToAdd只填财务应用的 ID动作位给canView: true、canEdit: false环境位只留canAccessReleased: true默认值——成员只能看到已发布版本数据源资源不创建。不给canConfigure/canUse财务成员就无法在构建器里触碰任何连接文件夹资源按需给一个包含财务应用的文件夹canViewApps: true让应用在工作台按文件夹聚合展示。加人邀请新成员后直接在「Workspace settings → Users」中将其加入Finance Team。由于该组不含构建级权限不会触发角色变更确认弹窗兜底如果后续业务要求某位财务成员能维护看板不要改组权限——应单独把 ta 移入 Builder 组再针对 ta 所在组按规则四走allowRoleChange流程升级保持审计链路清晰。日常调整用户所属组的完整操作步骤见官方文档 user-roles.md要点回顾ToolJet 的权限体系一句话概括组织 → 用户组三角色默认组 自定义组→ 组级权限位 细粒度资源授权两级权限分别回答「能不能」和「对哪些资源」组级开关直接落在permission_groups表的布尔列上资源级授权落在granular_permissions及其级联子表上删组即级联清理三条硬约束Admin 组细粒度权限不可改、End-user 不可获得任何构建级权限、多环境访问受MULTI_ENVIRONMENT许可证门控所有建组、加人、改授权操作均带审计日志与许可证校验可放心用于生产环境的多团队治理。延伸阅读均在仓库内权限概念总览permissions.md角色与访问控制user-roles.md、access-control.md、custom-groups.md源码入口group-permissions 模块【免费下载链接】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 权限体系实战指南：默认角色、自定义组与细粒度权限全解析
ToolJet 用户组与 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/ToolJetToolJet 的权限管理基于角色访问控制Role-Based Access ControlRBAC构建一切授权都围绕「用户组Group」展开通过用户组内的权限位和细粒度权限Granular Permissions两个维度精确限定谁能创建应用、谁能查看数据源、谁能进入生产环境。对于自建部署或多团队协作场景理解 ToolJet 权限模型能帮助你快速设计出「按团队隔离、按环境收敛」的访问控制方案。权限全景组织、用户组与两级权限怎么层层嵌套ToolJet 的授权链条可以拆成三级每一级都对应数据库中的真实表结构组织Organization / Workspace——权限的隔离边界。所有组、权限记录、许可证条款都挂在组织之下跨组织之间天然互不可见。组的落库实体是 group_permissions.entity.ts其中organization_id字段即组织外键用户组Group——用户与权限之间的中间层。每个组织自带三个默认角色组也可以自建任意命名的自定义组。组成员关系由GroupUsers关联表维护删除组时级联清理权限Permissions——分两级组级权限位Group-level flags回答「这个组能不能做某类事」例如能否建应用、能否管理工作空间常量。它们直接以布尔列的形式存在permission_groups表上细粒度资源授权Granular Permissions回答「能做哪些具体资源」独立存储于 granular_permissions.entity.ts按应用、文件夹、数据源、工作流等类型逐条授权。组实体的核心字段大致如下完整定义见源码Entity({ name: permission_groups }) export class GroupPermissions extends BaseEntity { Column({ name: organization_id, nullable: false }) organizationId: string; Column({ name: name, nullable: false }) name: string; Column({ name: type, type: enum, enum: GROUP_PERMISSIONS_TYPE }) type: GROUP_PERMISSIONS_TYPE; // default | custom // appCreate / appDelete / folderCreate / orgConstantCRUD / // tjdbCRUD / dataSourceCreate / appPromote / appRelease ... OneToMany(() GroupUsers, (g) g.group, { onDelete: CASCADE }) groupUsers: GroupUsers[]; OneToMany(() GranularPermissions, (g) g.group, { onDelete: CASCADE }) groupGranularPermissions: GranularPermissions[]; }可以看到组既是一堆布尔开关的集合又通过一对多关系挂接了成员列表和细粒度授权。实体上还预留了PageUser、QueryUser、ComponentUser关联说明页面、查询、组件级的访问控制同样以「组」为授权单位。内置角色对比Admin、Builder、End-user 各自能做什么ToolJet 在 group-permissions 模块的 constants 中以USER_ROLE枚举定义了三个默认角色。三者能力差异可概括为下表能力维度 AdminBuilderEnd-user创建 / 删除应用appCreate / appDelete✅✅❌创建 / 删除工作流、模块及对应文件夹✅✅❌管理工作空间常量orgConstantCRUD✅✅❌操作内置数据库tjdbCRUD✅✅❌创建 / 删除数据源dataSourceCreate / dataSourceDelete✅✅❌应用晋级与发布appPromote / appRelease✅✅❌是否属于构建级isBuilderLevel✅✅❌几个要点在这一层Builder 与 Admin 的组级开关完全等价源码中两者共享同一套true配置两者的实际差别体现在下一层的资源级授权上比如环境访问范围End-user 的所有开关全部为false且isBuilderLevel: false——这是后文「End-user 硬边界」校验的根源官方角色说明可参考 user-roles.md访问控制全景见 access-control.md。组本身也分两种类型由GROUP_PERMISSIONS_TYPE枚举区分default默认组即上表三个内置角色组每个组织自动创建行为由系统约定custom自定义组管理员自由命名、自由配权限、自由加人且可以携带构建级权限是多团队隔离的主力工具。创建自定义组建组、配权限、加成员三步走在 group-permissions 的 service.ts 中组的生命周期操作都带审计日志和许可证校验对应到界面操作就是三步第一步建组并配置组级权限位调用create方法落库后写入审计日志。你可以直接勾选该组需要的能力位应用增删、常量管理、数据源管理……。注意复制组duplicateGroup支持三个开关——addPermission复制权限位、addUsers同步原组成员、addApps复制应用级细粒度授权之后仍会调用licenseUserService.validateUser校验组织用户配额许可证约束在复制时同样生效。第二步配置细粒度资源授权这一步决定「哪些具体资源」详见下一节。界面效果参考下图第三步把成员加入组addGroupUsers在事务内批量写入GroupUsers关联记录USER_ADD_TO_GROUP审计事件并做许可证校验getAddableUser则提供「谁可以被拉进这个组」的搜索列表。也就是说「建组 → 配权限 → 加人」每一步在后端都是可审计、受许可证约束的操作。更多细节见 custom-groups.md。细粒度权限配置把授权精确到具体应用、文件夹与数据源组级权限位只说「能不能」说「对谁哪个资源」的是细粒度权限。其核心实体GranularPermissions包含四个关键字段type资源类型取自ResourceType枚举共七类——app应用、data_source数据源、workflow工作流、folder文件夹、module模块、workflow_folder工作流文件夹、module_folder模块文件夹name授权名称组内唯一源码中对应唯一约束GRANULAR_PERMISSIONS_NAME_UNIQUEisAll全集标志默认true表示该类型下的全部资源都在授权范围内无需枚举置为false时通过GroupApps/GroupFolders等中间表逐个绑定具体资源 ID动作位按资源类型一对一挂接子表AppsGroupPermissions/DataSourcesGroupPermissions/FoldersGroupPermissions均为级联删除承载具体的操作权限。各默认角色的资源级默认值在DEFAULT_RESOURCE_PERMISSIONS常量中给出摘出最重要的应用资源维度角色canEdit编辑canView查看开发环境预发环境生产环境已发布版本Admin✅—✅✅✅✅Builder✅—✅✅❌✅End-user❌✅❌❌❌✅其他资源类型的动作位各有三档数据源canConfigure配置 / 管理与canUse仅使用二选一文件夹canEditFolder/canEditApps/canViewApps单选层级注释中明确说明「只把选中的那档置 true隐含权限在运行时推导」例如拥有「编辑文件夹」即运行时推导出「查看应用」能力模块Module与 End-user 完全不兼容模块永远不会分配给 end-user。对外 API 的入口与鉴权开关集中在模块的 granular-permissions.controller.ts 与 controller.ts每个操作对应FEATURE_KEY枚举中的一个键如CREATE_GRANULAR_APP_PERMISSIONS、CREATE_GRANULAR_FOLDER_PERMISSIONS、ASSIGN_GROUP_ADMIN控制器据此做功能级门禁。安全边界Admin 组不可改、End-user 硬边界与许可证门控真正的防御逻辑集中在 granular-permissions.util.service.ts有四条规则值得逐条理解。规则一Admin 默认组禁止配置细粒度权限validateGranularPermissionCreateOperation一旦发现目标组名是admin直接抛出ADMIN_DEFAULT_GROUP_GRANULAR_PERMISSIONS异常「Cannot create granular permissions of admin group」。Admin 的权限是系统全量约定的不允许通过接口收窄或扩大避免一次误操作让管理员失权。规则二End-user 组的构建级权限硬边界只要目标组内存在 end-user 成员以下授权请求会被拒绝资源类型被拒绝的动作位备注应用 / 工作流canEdit编辑属于构建级能力模块canView也一并拒绝模块永远不会分配给 end-user数据源canConfigure、canUse使用数据源本身就是构建级能力文件夹canEditFolder、canEditApps查看类不受限模块文件夹任何授权一律拒绝拒绝时返回结构化的400响应type为USER_ROLE_CHANGE_ADD_PERMISSIONSdata字段携带组内所有end-user 的邮箱——前端就是靠这个列表弹出「需要变更哪些用户角色」的提示。规则三环境访问权限与多环境许可证联动validateEnvironmentPermissions在请求涉及canAccessDevelopment/canAccessStaging/canAccessProduction时会先查询组织是否持有MULTI_ENVIRONMENT许可证条款licenseTermsService.getLicenseTerms。未持有多环境许可证的组织连给 Builder 配置环境访问都会被 end-user 拒绝逻辑拦截——多环境隔离能力本身是许可证门控的自建部署时这一点容易被忽略。规则四可选的角色自动升级allowRoleChange更新授权时若请求携带allowRoleChange: truevalidateResourceAction确认这是一次构建级变更且组内确有 end-user 时会调用roleUtilService.changeEndUserToEditor把他们批量升级为 builder否则抛出USER_ROLE_CHANGE类型的错误。前端「变更组权限后弹出角色变更确认」的交互源头就在这里。实战示例为「财务团队」设计一套最小权限方案把上面的机制串起来给一个典型的多团队场景设计权限。目标财务团队只接触财务相关应用和工作空间常量不碰生产环境也不具备构建能力。建组创建一个自定义组Finance Teamtype: custom只勾选orgConstantCRUD: true其余应用 / 数据源 / 文件夹类能力位全部保持false配细粒度授权应用资源isAll falseresourcesToAdd只填财务应用的 ID动作位给canView: true、canEdit: false环境位只留canAccessReleased: true默认值——成员只能看到已发布版本数据源资源不创建。不给canConfigure/canUse财务成员就无法在构建器里触碰任何连接文件夹资源按需给一个包含财务应用的文件夹canViewApps: true让应用在工作台按文件夹聚合展示。加人邀请新成员后直接在「Workspace settings → Users」中将其加入Finance Team。由于该组不含构建级权限不会触发角色变更确认弹窗兜底如果后续业务要求某位财务成员能维护看板不要改组权限——应单独把 ta 移入 Builder 组再针对 ta 所在组按规则四走allowRoleChange流程升级保持审计链路清晰。日常调整用户所属组的完整操作步骤见官方文档 user-roles.md要点回顾ToolJet 的权限体系一句话概括组织 → 用户组三角色默认组 自定义组→ 组级权限位 细粒度资源授权两级权限分别回答「能不能」和「对哪些资源」组级开关直接落在permission_groups表的布尔列上资源级授权落在granular_permissions及其级联子表上删组即级联清理三条硬约束Admin 组细粒度权限不可改、End-user 不可获得任何构建级权限、多环境访问受MULTI_ENVIRONMENT许可证门控所有建组、加人、改授权操作均带审计日志与许可证校验可放心用于生产环境的多团队治理。延伸阅读均在仓库内权限概念总览permissions.md角色与访问控制user-roles.md、access-control.md、custom-groups.md源码入口group-permissions 模块【免费下载链接】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），仅供参考
