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 是用于搭建内部工具、仪表盘和业务应用的开源低代码平台其 RBAC 权限模型围绕用户组 细粒度授权构建工作空间角色管理与多环境访问边界都落在权限位、资源授权记录两组结构里。三个团队进场财务只能看财务应用假设一家公司自建部署 ToolJet财务团队只想看到报销和预算应用运维团队只关心监控看板而搭建者需要随时改东西。如果账号发下去全靠口头约定谁别碰什么越界迟早会发生。ToolJet 的 RBACRole-Based Access Control基于角色的访问控制权限模型回答的是两个问题能不能做这类操作和能操作哪些资源前者叫组级权限位是一串挂在组记录上的布尔开关后者叫资源级授权即细粒度权限granular permission一条针对具体资源的授权记录。两层的分工很清晰开关层管能力授权层管范围合起来才决定一个成员最终能碰到什么。换句话说Admin 只需要做三件事——建组、翻开关、圈资源。在数据层这两层结构都挂在组织Organization/Workspace这个权限隔离边界之下。组本身存在permission_groups表里实体定义见 server/src/entities/group_permissions.entity.ts成员通过group_users关联表挂载整组的资源授权清单则挂在granular_permissions之下。后来页面、查询、组件这几类资源的授权也统一以组为授权单位而不是个人。Admin、Builder、End-user一张表看清能力边界⚙️ 每个组织自动初始化三个默认组官方文档 user-roles.md 对三者分工的概括是Admin 管一切Builder 搭应用End-user 用应用。落到具体能力上是这样一张矩阵资源维度操作AdminBuilderEnd-user应用 / 工作流 / 文件夹创建、更新、删除✅✅❌数据源配置与管理✅✅❌工作空间常量 / 变量增删改✅✅❌ToolJet 内置数据库TJDB操作✅✅❌应用生产环境访问✅❌❌开发 / 预发环境访问✅✅❌Released 已发布版本查看✅✅✅容易误读的是查看这一行canEdit与canView是互斥的动作位一个角色对某个应用要么编辑要么查看不存在两者兼得。注意组级开关上 Admin 与 Builder 是逐位等价的源码里两个常量的字段完全一致真正的分水岭在资源级——Builder 默认进不了生产环境End-user 只剩canView Released两个位。这些默认值写在 constants/index.ts 的DEFAULT_GROUP_PERMISSIONS与DEFAULT_RESOURCE_PERMISSIONS里每个自定义组的空白画布都从这里起步。ToolJet 自定义组配置四步搭出一个专属团队 官方文档 custom-groups.md 从界面视角描述了同一条链路后端实现集中在 service.ts。你可以按四步记忆第一步建组。组的增删改查入口在create方法落库的同时往审计日志写一条GROUP_PERMISSION_CREATE记录谁建了什么组可以追溯。第二步配组级开关。这一层只回答能不能做这类事。以 end-user 默认组为例它的常量是这样一片END_USER: { name: USER_ROLE.END_USER, orgConstantCRUD: false, isBuilderLevel: false, }这段说明了 end-user 组在组级层面全部关闭连isBuilderLevel标记本身都是 false——它是后面所有构建级拒绝逻辑的判断依据。第三步圈资源范围。一条细粒度权限记录在一次事务里完成核心字段只有四个name、type、groupId、isAllconst granularPermissions manager.create(GranularPermissions, { name, type, groupId, isAll }); return await manager.save(granularPermissions); if (isAll) { createResourcePermissionsObj.resourcesToAdd []; }这段说明了授权主记录与具体资源清单同事务写入授权名称带唯一约束同一组不会出现两条同类型授权isAlltrue时资源枚举直接清空。第四步拉人入组。addGroupUsers在事务内批量写入group_users关联记录USER_ADD_TO_GROUP审计事件同时调用许可证的用户配额校验——带坐席上限的组织这一步会被直接卡住。一个用户可以同时属于多个组组间授权叠加生效。还有个快捷方式duplicateGroup支持三个开关——addPermission复制权限位、addUsers同步原组成员、addApps复制应用级授权。当组织里已经沉淀出财务团队模板给新团队复制一个组的成本就是一次点击。圈出财务只看 3 个应用ResourceType、isAll 与三张级联表每条授权记录有两个形状字段type声明资源类别isAll声明覆盖范围。type取自ResourceType枚举共 7 个取值app、data_source、workflow、folder、module、workflow_folder、module_folder。isAlltrue默认授权覆盖该类资源全集无需逐个枚举isAllfalse通过group_apps/group_folders等中间表逐个关联具体资源 ID财务团队只看 3 个应用就是这种形态每类授权的动作位再挂在三张一对一表上apps_group_permissions应用动作 4 个环境位、data_sources_group_permissions数据源动作、folders_group_permissions文件夹档位定义都在 granular_permissions.entity.tsOneToOne(() AppsGroupPermissions, (appsGroupPermission) appsGroupPermission.granularPermissions, { onDelete: CASCADE, }) appsGroupPermissions: AppsGroupPermissions;这段说明了动作数据以级联方式挂在授权记录之下删除一条授权即自动清理对应资源的具体动作回收权限只是一次删除操作。三个默认角色的应用资源默认授权如下4 个环境位正是多环境门控的挂载点——许可证校验就发生在这几个开关写入之前角色canEditcanView开发预发生产已发布Admin✅—✅✅✅✅Builder✅—✅✅❌✅End-user❌✅❌❌❌✅数据源用canConfigure/canUse两个位文件夹用canEditFolder/canEditApps/canViewApps三档单选关系低档位隐含高档位的权限运行时推导。四条硬规则踩中就拒⚠️ 细粒度授权接口的安全校验集中在 granular-permissions.util.service.tsToolJet end-user 权限限制以四条硬规则在这里强制执行命中即拒1. Admin 组锁定规则Admin 默认组不允许创建或更新细粒度权限直接抛 400。 触发目标组名命中USER_ROLE.ADMIN。 意图Admin 的权限是系统级全量约定允许逐条调整的话一次误操作就能让整个组织的管理员失权。2. End-user 构建级拒绝规则end-user 组不能持有任何构建级授权。 触发应用/工作流canEdittrue即拒module 更严canView也拒数据源canConfigure/canUse任一为 true 即拒文件夹canEditFolder/canEditApps即拒。 意图把消费者钉死在消费侧报错体会带上组内全部 end-user 的邮箱type 为USER_ROLE_CHANGE_ADD_PERMISSIONS管理员能直接定位该调谁的角色。3. 多环境许可证门控规则授予开发/预发/生产任一环境位先查组织是否持有MULTI_ENVIRONMENT许可证条款。 触发actions含三个环境位之一且许可证查询返回 false。 意图多环境隔离本身是许可功能接口层改了开关许可证服务也不放行。4. 角色自动升级需显式确认规则给含 end-user 的组授予构建级权限请求必须显式带allowRoleChange: true否则抛 405。 触发validateResourceAction确认是构建级或环境级更新且组内有 end-user 时allowRoleChangetrue调changeEndUserToEditor批量升为 builder否则抛USER_ROLE_CHANGE。 意图把改权限 改角色这个隐式后果变成前端弹窗里的显式确认。日常操作速查五步改一个用户的角色ToolJet 工作空间角色管理本质上就是换用户所在的组改权限跟着走点工作台左下角的设置 ⚙️ 图标进入Workspace settings → Users在目标用户行尾点 ⋮ 菜单选Edit user details右侧 User groups 下拉里切换到目标组比如 Finance Team点Update弹窗警告里点Continue确认。注意当目标组带构建级权限、而该用户当前是 end-user 时第 5 步会触发规则 4 的确认交互——这是正常流程不是报错。回到开篇的场景财务团队进了 Finance Team 组该组的应用授权isAllfalse、只圈了 3 个财务应用工作空间常量开关打开环境访问只到 Released运维是另一个组搭建者留在默认 Builder 组默认进不了生产。理解权限位 资源授权两层数据和上面四条硬规则之后你在自建实例上做的就不只是发账号而是设计一套可审计、受许可证约束的团队 × 资源访问矩阵。【免费下载链接】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），仅供参考