ToolJet 用户角色User Roles详解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 开源低代码平台的用户角色User Roles机制展开深入解析工作区Workspace级别的三种默认角色 —— Admin管理员、Builder构建者、End-user终端用户—— 各自的职责边界与资源权限矩阵并给出管理员如何在Workspace Settings Users中修改用户角色的完整操作步骤。读者将掌握 ToolJet RBAC 的权限分层原理、默认角色在源码中的真实定义以及如何在日常运维中安全地变更用户角色。一、ToolJet 的 RBAC角色、组与权限的三层模型ToolJet 通过基于角色的访问控制RBAC体系来管理应用、数据源、文件夹、工作区常量/变量等资源的安全与访问。其权限体系可以拆解为三个层面用户角色User Roles系统预置的角色决定用户在某一工作区内的基准权限自定义组Custom Groups支持更细粒度的权限控制可将用户按团队或职责分组并赋予特定权限资源级权限Granular Access Control对单个应用、数据源等资源设置 View / Edit / Configure 等具体权限。角色与组共同参与用户的权限判定而用户角色还会被纳入许可Licensing与计费的考量范围。从源码结构看用户角色与自定义组共用同一套组权限Group Permissions机制默认角色本质上是系统预置的、不可删除的默认组。三者关系可参考配套文档access-control.md 与 custom-groups.md。二、三种默认用户角色Default User RolesToolJet 在工作区级别预置了三种默认用户角色权限逐级递减角色定位核心职责Admin工作区管理员管理设置、控制用户权限、监督整体功能拥有全部资源的完整访问权Builder应用构建者负责应用的创建、定制与配置权限可被精细配置End-user终端用户消费最终应用执行任务或达成业务目标只能查看和使用被授权访问的已发布应用源码中的角色定义这三种角色的定义可以在服务端源码 server/src/modules/group-permissions/constants/index.ts 中找到它们被定义为枚举USER_ROLE与三个默认组对象export enum USER_ROLE { END_USER end-user, ADMIN admin, BUILDER builder, }其中DEFAULT_GROUP_PERMISSIONS定义了各角色的全局开关型权限如appCreate、dataSourceCreate、folderCreate、appPromote、appRelease等DEFAULT_RESOURCE_PERMISSIONS则定义了角色在各类资源App、Data Source、Folder、Workflow、Module 等上的默认动作权限。此外server/src/modules/ability/constants.ts 中的DEFAULT_USER_PERMISSIONS为每个用户维护了isAdmin、isBuilder、isEndUser三个角色标志位以及各资源的细粒度权限列表是后端进行权限判定的基础数据。注工作区级角色之上还存在实例级的 Super Admin超级管理员概念二者作用域不同可参考 super-admin.md。三、各角色的权限矩阵Permissions for User Roles默认情况下Admin 拥有工作区级别的全部权限End-user 只能查看并使用被授权访问的已发布应用Builder 的权限则可以被管理员按需配置。三种角色的基准权限矩阵如下资源权限AdminBuilderEnd UserAppsCreate/Update/Delete✅可配置❌View✅可配置可配置Data sourcesCreate/Update/Delete✅可配置❌FolderCreate/Update/Delete✅可配置❌Workspace constants/variablesCreate/Update/Delete✅可配置❌从源码印证默认权限差异对照 DEFAULT_GROUP_PERMISSIONS 可以看出三个角色的默认差异Admin / BuilderappCreate、appDelete、folderCreate、folderDelete、dataSourceCreate、dataSourceDelete、orgConstantCRUD、appPromote、appRelease等开关均为true且都带isBuilderLevel: true标志End-user上述所有开关均为falseisBuilderLevel也为false即默认没有任何创建/删除类权限。而在资源默认权限DEFAULT_RESOURCE_PERMISSIONS中三者的差异更加明显Admin可编辑 AppcanEdit: true可访问 Development / Staging / Production / Released 全部环境canAccessDevelopment/Staging/Production/Released均为true数据源可配置canConfigure: trueBuilder可编辑 App默认可访问 Development、Staging 与 Released 环境但Production 环境默认为falsecanAccessProduction: false数据源同样可配置End-userApp 默认可查看canView: true但不可编辑canEdit: false仅可访问 Released已发布环境其余环境均不可访问。这一设计清晰地体现了 构建者管开发、终端用户只用成品 的权限隔离思路。四、管理用户角色修改用户角色的完整步骤修改用户角色需要Admin权限操作路径为工作区管理后台点击仪表盘左下角的设置图标⚙️进入Workspace settings Users示例 URLhttps://app.corp.com/nexus/workspace-settings/users在用户列表中找到需要调整角色的用户点击该行末尾的kebab 菜单⋮点击Edit user details右侧将弹出用户详情面板在User groups下拉框中更新该用户的角色点击面板底部的Update按钮阅读并接受弹出窗口中的警告点击Continue确认确认后该用户的角色即完成更新。角色变更背后的权限联动从服务端实现看角色变更并非孤立的用户字段更新。在 server/src/modules/users/repositories/repository.ts 中用户与角色/组通过user.userGroups关联表关联后端会按group.name如USER_ROLE.ADMIN与organizationId查询并判定用户的有效角色集合roles: USER_ROLE[]。因此修改用户角色实际上是在调整该用户与默认组/自定义组的隶属关系当用户被加入权限更高的自定义组时其角色会被自动提升见 custom-groups.md 中的 Inheritance and Overrides 规则当用户角色被降级到更低权限时系统会将其从提供更高权限的自定义组中自动移除避免越权残留。这就是第 7 步警告弹窗存在的意义角色变更可能连带影响用户所属的自定义组需要管理员二次确认。五、权限的继承与叠加规则理解角色权限还需要掌握权限的叠加逻辑用户同时继承所属角色与所属自定义组的权限当用户属于多个组时取任意一组中授予的最高权限取并集用户拥有资源的创建权并创建该资源后自动成为资源 Owner默认获得该资源的全部相关权限例如创建了数据源 A 的用户默认拥有数据源 A 的 Configure 与 Build 权限该规则在 access-control.md 中有明确说明。六、与其他权限文档的衔接用户角色是 ToolJet 权限体系的入口后续深入阅读建议访问控制access-control.md —— 讲解 Apps / Data Sources / Folder / Workspace 常量的创建与删除权限配置以及 Granular Access Control粒度级访问控制的 Edit / View / Configure / Build with 等资源级权限自定义组custom-groups.md —— 讲解如何创建、删除、复制自定义组以及权限的继承与覆盖规则超级管理员super-admin.md —— 讲解实例级 Super Admin 与工作区级角色Admin/Builder/End-user的区别。小结ToolJet 的用户角色体系以 Admin、Builder、End-user 三种默认角色为骨架配合自定义组与粒度级资源权限构成了一套完整、可伸缩的工作区访问控制方案。管理员既可以通过Workspace Settings Users快速调整单个用户的角色也可以通过自定义组实现按团队、按应用的精细授权。理解默认角色的权限边界尤其是 Builder 默认不可访问 Production 环境、End-user 仅可访问 Released 环境是安全治理工作区权限的第一步。【免费下载链接】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 Roles）详解：RBAC 权限模型与工作区角色管理实战
ToolJet 用户角色User Roles详解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 开源低代码平台的用户角色User Roles机制展开深入解析工作区Workspace级别的三种默认角色 —— Admin管理员、Builder构建者、End-user终端用户—— 各自的职责边界与资源权限矩阵并给出管理员如何在Workspace Settings Users中修改用户角色的完整操作步骤。读者将掌握 ToolJet RBAC 的权限分层原理、默认角色在源码中的真实定义以及如何在日常运维中安全地变更用户角色。一、ToolJet 的 RBAC角色、组与权限的三层模型ToolJet 通过基于角色的访问控制RBAC体系来管理应用、数据源、文件夹、工作区常量/变量等资源的安全与访问。其权限体系可以拆解为三个层面用户角色User Roles系统预置的角色决定用户在某一工作区内的基准权限自定义组Custom Groups支持更细粒度的权限控制可将用户按团队或职责分组并赋予特定权限资源级权限Granular Access Control对单个应用、数据源等资源设置 View / Edit / Configure 等具体权限。角色与组共同参与用户的权限判定而用户角色还会被纳入许可Licensing与计费的考量范围。从源码结构看用户角色与自定义组共用同一套组权限Group Permissions机制默认角色本质上是系统预置的、不可删除的默认组。三者关系可参考配套文档access-control.md 与 custom-groups.md。二、三种默认用户角色Default User RolesToolJet 在工作区级别预置了三种默认用户角色权限逐级递减角色定位核心职责Admin工作区管理员管理设置、控制用户权限、监督整体功能拥有全部资源的完整访问权Builder应用构建者负责应用的创建、定制与配置权限可被精细配置End-user终端用户消费最终应用执行任务或达成业务目标只能查看和使用被授权访问的已发布应用源码中的角色定义这三种角色的定义可以在服务端源码 server/src/modules/group-permissions/constants/index.ts 中找到它们被定义为枚举USER_ROLE与三个默认组对象export enum USER_ROLE { END_USER end-user, ADMIN admin, BUILDER builder, }其中DEFAULT_GROUP_PERMISSIONS定义了各角色的全局开关型权限如appCreate、dataSourceCreate、folderCreate、appPromote、appRelease等DEFAULT_RESOURCE_PERMISSIONS则定义了角色在各类资源App、Data Source、Folder、Workflow、Module 等上的默认动作权限。此外server/src/modules/ability/constants.ts 中的DEFAULT_USER_PERMISSIONS为每个用户维护了isAdmin、isBuilder、isEndUser三个角色标志位以及各资源的细粒度权限列表是后端进行权限判定的基础数据。注工作区级角色之上还存在实例级的 Super Admin超级管理员概念二者作用域不同可参考 super-admin.md。三、各角色的权限矩阵Permissions for User Roles默认情况下Admin 拥有工作区级别的全部权限End-user 只能查看并使用被授权访问的已发布应用Builder 的权限则可以被管理员按需配置。三种角色的基准权限矩阵如下资源权限AdminBuilderEnd UserAppsCreate/Update/Delete✅可配置❌View✅可配置可配置Data sourcesCreate/Update/Delete✅可配置❌FolderCreate/Update/Delete✅可配置❌Workspace constants/variablesCreate/Update/Delete✅可配置❌从源码印证默认权限差异对照 DEFAULT_GROUP_PERMISSIONS 可以看出三个角色的默认差异Admin / BuilderappCreate、appDelete、folderCreate、folderDelete、dataSourceCreate、dataSourceDelete、orgConstantCRUD、appPromote、appRelease等开关均为true且都带isBuilderLevel: true标志End-user上述所有开关均为falseisBuilderLevel也为false即默认没有任何创建/删除类权限。而在资源默认权限DEFAULT_RESOURCE_PERMISSIONS中三者的差异更加明显Admin可编辑 AppcanEdit: true可访问 Development / Staging / Production / Released 全部环境canAccessDevelopment/Staging/Production/Released均为true数据源可配置canConfigure: trueBuilder可编辑 App默认可访问 Development、Staging 与 Released 环境但Production 环境默认为falsecanAccessProduction: false数据源同样可配置End-userApp 默认可查看canView: true但不可编辑canEdit: false仅可访问 Released已发布环境其余环境均不可访问。这一设计清晰地体现了 构建者管开发、终端用户只用成品 的权限隔离思路。四、管理用户角色修改用户角色的完整步骤修改用户角色需要Admin权限操作路径为工作区管理后台点击仪表盘左下角的设置图标⚙️进入Workspace settings Users示例 URLhttps://app.corp.com/nexus/workspace-settings/users在用户列表中找到需要调整角色的用户点击该行末尾的kebab 菜单⋮点击Edit user details右侧将弹出用户详情面板在User groups下拉框中更新该用户的角色点击面板底部的Update按钮阅读并接受弹出窗口中的警告点击Continue确认确认后该用户的角色即完成更新。角色变更背后的权限联动从服务端实现看角色变更并非孤立的用户字段更新。在 server/src/modules/users/repositories/repository.ts 中用户与角色/组通过user.userGroups关联表关联后端会按group.name如USER_ROLE.ADMIN与organizationId查询并判定用户的有效角色集合roles: USER_ROLE[]。因此修改用户角色实际上是在调整该用户与默认组/自定义组的隶属关系当用户被加入权限更高的自定义组时其角色会被自动提升见 custom-groups.md 中的 Inheritance and Overrides 规则当用户角色被降级到更低权限时系统会将其从提供更高权限的自定义组中自动移除避免越权残留。这就是第 7 步警告弹窗存在的意义角色变更可能连带影响用户所属的自定义组需要管理员二次确认。五、权限的继承与叠加规则理解角色权限还需要掌握权限的叠加逻辑用户同时继承所属角色与所属自定义组的权限当用户属于多个组时取任意一组中授予的最高权限取并集用户拥有资源的创建权并创建该资源后自动成为资源 Owner默认获得该资源的全部相关权限例如创建了数据源 A 的用户默认拥有数据源 A 的 Configure 与 Build 权限该规则在 access-control.md 中有明确说明。六、与其他权限文档的衔接用户角色是 ToolJet 权限体系的入口后续深入阅读建议访问控制access-control.md —— 讲解 Apps / Data Sources / Folder / Workspace 常量的创建与删除权限配置以及 Granular Access Control粒度级访问控制的 Edit / View / Configure / Build with 等资源级权限自定义组custom-groups.md —— 讲解如何创建、删除、复制自定义组以及权限的继承与覆盖规则超级管理员super-admin.md —— 讲解实例级 Super Admin 与工作区级角色Admin/Builder/End-user的区别。小结ToolJet 的用户角色体系以 Admin、Builder、End-user 三种默认角色为骨架配合自定义组与粒度级资源权限构成了一套完整、可伸缩的工作区访问控制方案。管理员既可以通过Workspace Settings Users快速调整单个用户的角色也可以通过自定义组实现按团队、按应用的精细授权。理解默认角色的权限边界尤其是 Builder 默认不可访问 Production 环境、End-user 仅可访问 Released 环境是安全治理工作区权限的第一步。【免费下载链接】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），仅供参考