ToolJet 用户角色与 RBAC 权限体系全解析Admin、Builder 与 End-user 的角色管理实战【免费下载链接】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 官方用户管理文档系统讲解 ToolJet 基于角色的访问控制RBAC体系三个内置默认角色Admin、Builder、End-user各自的权限边界、工作区级别的权限矩阵以及管理员如何通过Workspace Settings Users页面为单个用户更新角色。读完本文你将掌握 ToolJet 角色的完整管理流程理解角色与自定义组的继承/覆盖规则并能从源码层面看懂角色在服务端与前端的具体实现。ToolJet 将 RBAC 作为整个权限体系的地基无论是应用Apps、数据源Data sources、文件夹Folder还是工作区常量/变量Workspace constants/variables其访问控制都建立在用户角色与用户组之上。这套体系不仅管理安全访问还会被计入授权licensing与计费逻辑因此正确理解与配置角色是使用 ToolJet 的前提。角色在 ToolJet 权限体系中的位置在深入角色细节之前先厘清 ToolJet 权限模型的核心概念。根据 tooljet-concepts/permissions.md 的说明ToolJet 的 RBAC 体系由三个基本要素组成User用户被 Admin 邀请进入工作区的成员Group组包含一组用户每个组关联一组权限Permission权限决定组成员对各类资源拥有何种级别的访问能力。在这个模型中默认角色Default Roles与自定义组Custom Groups共同决定了用户在工作区内的访问层级。默认角色开箱即用、覆盖绝大多数常见场景自定义组如 Support、Engineering、Finance则用于更细粒度的访问控制例如只允许某个团队访问与自身业务相关的应用。三个默认用户角色ToolJet 在工作区workspace级别定义了三个默认角色每个角色拥有不同层级的访问能力见 user-roles.md角色定位核心职责Admin工作区管理者管理设置、控制用户权限、监督整体功能对全部资源拥有完整访问权限Builder应用构建者负责创建、定制和配置应用程序End-user最终使用者与已发布的应用交互执行任务或达成特定目标从源码角度看这三个角色在服务端被定义为一组枚举值。在 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, }同时GROUP_PERMISSIONS_TYPE.DEFAULT标记了默认角色组与自定义组的区别——默认角色本质上也是一种“组”只是由系统预置且不可删除。在数据迁移辅助文件 server/src/migration-helpers/constants.ts 中DEFAULT_GROUP_PERMISSIONS_MIGRATIONS定义了ADMIN等默认组在初始化时的权限对象可以推断每个默认角色的权限是在数据库迁移阶段预置的与通过 UI 创建的自定义组走的是同一套组权限表group_permissions这保证了角色与自定义组能够统一地被权限引擎处理。角色权限矩阵Admin 在工作区级别拥有全部权限End-user 只能查看和使用被授予访问权的已发布应用Builder 的权限则是“可配置的”Configurable即可以由 Admin 按需调整。官方权限矩阵如下资源权限AdminBuilderEnd UserAppsCreate/Update/Delete✅Configurable❌View✅ConfigurableConfigurableData sourcesCreate/Update/Delete✅Configurable❌FolderCreate/Update/Delete✅Configurable❌Workspace constants/variablesCreate/Update/Delete✅Configurable❌对照 access-control.md 中的权限说明可以进一步理解这些“Configurable”权限的具体语义资源权限说明AppsCreate允许组内用户在工作区中创建新应用Delete允许组内用户从工作区删除应用Data sourcesCreate允许组内用户在工作区中新增数据源Delete允许组内用户移除工作区中的数据源FolderCreate/Update/Delete允许组内用户创建、更新或删除文件夹以组织资源Workspace constants/variablesCreate/Update/Delete允许组内用户定义、修改或移除工作区范围内使用的常量与变量关于“View”类权限如表中的 Apps View、数据源的使用权限官方明确建议通过Granular Access Control粒度访问控制来配置例如对应用可授予Edit可编辑/构建、View仅查看已发布版本并执行任务或Hide from dashboard从仪表盘隐藏、仅可通过 URL 访问等权限对数据源可授予Configure可查看并编辑数据源配置或Build with可在应用与工作流中基于该数据源创建查询权限。权限配置的默认行为根据 access-control.md 中的一个重要说明如果用户拥有 Create 权限并创建了某个资源该用户自动成为此资源的 owner默认获得与该资源相关的全部权限。例如用户创建数据源 A 后默认就拥有对数据源 A 的 Configure 和 Build with 访问权。这意味着在规划权限时无需为资源创建者额外配置其“自己资源”的访问权。管理用户角色逐步操作指南更新用户角色需要Admin权限。完整步骤如下见 user-roles.md点击仪表盘左下角的设置图标⚙️。进入Workspace settings Users。 示例 URLhttps://app.corp.com/nexus/workspace-settings/users找到需要更新角色的用户点击其所在行末尾的 kebab 菜单⋮ 竖排三点按钮。该菜单在前端由 UsersActionMenu.jsx 实现菜单中包含Edit user details、Reset password允许重置他人密码以及Archive/Unarchive user等操作其中“Edit user details”按钮带有data-cyedit-user-details-button的测试标识点击后通过toggleEditUserDrawer()打开右侧编辑面板。点击Edit user details右侧将弹出编辑面板。在User groups下拉框中更新用户的角色/所属组。点击面板底部的Update按钮。阅读并接受弹出警告点击Continue确认。该用户的角色即更新完成。补充角色变更涉及的工作区权限审计在服务端通过FEATURE_KEY.USER_ROLE_CHANGE等特性键进行控制见 server/src/modules/group-permissions/constants/features.ts并且服务端对“编辑最后一个 Admin 角色”等敏感操作有明确限制见 server/src/modules/group-permissions/constants/error.ts 中的EDITING_LAST_ADMIN_ROLE_NOT_ALLOWED从实现层面防止工作区出现“无主”状态。角色与自定义组的继承与覆盖规则角色不是孤立存在的它与自定义组协同工作。当工作区同时存在默认角色与自定义组时遵循以下规则见 custom-groups.md继承用户继承其分配到的角色以及所属全部自定义组的权限自动升级将用户加入权限高于其当前角色的自定义组时系统会自动将其用户角色升级到与更高访问层级匹配自动移除若用户角色被降级到更低权限系统会自动将其从提供高于新角色权限的自定义组中移除取最高权限当用户属于多个组时取任意组授予的最高权限级别。这一“角色与组联动”的机制在服务端有对应实现。在 server/src/modules/auth/util.service.ts 中可以看到如下注释与逻辑// If any custom group is editable, ensure the role is at least builder - Not considering role mapping可以推断当用户的自定义组包含可编辑类builder 级别权限时系统会确保该用户的角色至少为 builder防止出现“组权限高于角色权限”的矛盾状态——这正是上述“自动升级”规则在代码层面的落地。同时error.ts 中的END_USER_DEFAULT_GROUP_...类错误如“End-user cannot have this builder level permissions”表明服务端会拒绝为 End-user 分配 builder 级权限的非法组合保证角色语义的一致性。实用建议最小权限原则与角色规划结合上述机制在生产环境中规划用户角色时可以参考以下实践先默认角色后自定义组绝大多数成员使用默认角色即可只有需要跨团队、按资源细分访问时才创建自定义组HR、Sales、Finance 等并结合粒度访问控制配置具体应用的 Edit/View 权限。明确 Builder 的“Configurable”边界Builder 的创建/删除权限并非固定Admin 应根据团队职责在Workspace Settings Groups中按需授予或回收参考 access-control.md 的“Configuring Permissions”小节。善用资源 owner 机制既然创建者自动成为资源 owner 并拥有全部相关权限可以将“创建资源”作为授权入口减少事后逐一配置的成本。变更角色时留意自动升级/移除将一个用户移入高权限组会触发角色自动升级反向操作则会自动将其从高权限组移除——这既是便利也是约束变更前应通盘评估影响面。进一步阅读自定义组指南创建、删除、复制自定义组以及继承/覆盖规则的完整说明访问控制指南工作区级权限与粒度访问控制的详细配置权限概念总览User、Group、Permission 三者关系与典型安全场景源码参考USER_ROLE 枚举定义、默认组权限迁移、用户操作菜单实现【免费下载链接】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 权限体系全解析：Admin、Builder 与 End-user 的角色管理实战
ToolJet 用户角色与 RBAC 权限体系全解析Admin、Builder 与 End-user 的角色管理实战【免费下载链接】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 官方用户管理文档系统讲解 ToolJet 基于角色的访问控制RBAC体系三个内置默认角色Admin、Builder、End-user各自的权限边界、工作区级别的权限矩阵以及管理员如何通过Workspace Settings Users页面为单个用户更新角色。读完本文你将掌握 ToolJet 角色的完整管理流程理解角色与自定义组的继承/覆盖规则并能从源码层面看懂角色在服务端与前端的具体实现。ToolJet 将 RBAC 作为整个权限体系的地基无论是应用Apps、数据源Data sources、文件夹Folder还是工作区常量/变量Workspace constants/variables其访问控制都建立在用户角色与用户组之上。这套体系不仅管理安全访问还会被计入授权licensing与计费逻辑因此正确理解与配置角色是使用 ToolJet 的前提。角色在 ToolJet 权限体系中的位置在深入角色细节之前先厘清 ToolJet 权限模型的核心概念。根据 tooljet-concepts/permissions.md 的说明ToolJet 的 RBAC 体系由三个基本要素组成User用户被 Admin 邀请进入工作区的成员Group组包含一组用户每个组关联一组权限Permission权限决定组成员对各类资源拥有何种级别的访问能力。在这个模型中默认角色Default Roles与自定义组Custom Groups共同决定了用户在工作区内的访问层级。默认角色开箱即用、覆盖绝大多数常见场景自定义组如 Support、Engineering、Finance则用于更细粒度的访问控制例如只允许某个团队访问与自身业务相关的应用。三个默认用户角色ToolJet 在工作区workspace级别定义了三个默认角色每个角色拥有不同层级的访问能力见 user-roles.md角色定位核心职责Admin工作区管理者管理设置、控制用户权限、监督整体功能对全部资源拥有完整访问权限Builder应用构建者负责创建、定制和配置应用程序End-user最终使用者与已发布的应用交互执行任务或达成特定目标从源码角度看这三个角色在服务端被定义为一组枚举值。在 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, }同时GROUP_PERMISSIONS_TYPE.DEFAULT标记了默认角色组与自定义组的区别——默认角色本质上也是一种“组”只是由系统预置且不可删除。在数据迁移辅助文件 server/src/migration-helpers/constants.ts 中DEFAULT_GROUP_PERMISSIONS_MIGRATIONS定义了ADMIN等默认组在初始化时的权限对象可以推断每个默认角色的权限是在数据库迁移阶段预置的与通过 UI 创建的自定义组走的是同一套组权限表group_permissions这保证了角色与自定义组能够统一地被权限引擎处理。角色权限矩阵Admin 在工作区级别拥有全部权限End-user 只能查看和使用被授予访问权的已发布应用Builder 的权限则是“可配置的”Configurable即可以由 Admin 按需调整。官方权限矩阵如下资源权限AdminBuilderEnd UserAppsCreate/Update/Delete✅Configurable❌View✅ConfigurableConfigurableData sourcesCreate/Update/Delete✅Configurable❌FolderCreate/Update/Delete✅Configurable❌Workspace constants/variablesCreate/Update/Delete✅Configurable❌对照 access-control.md 中的权限说明可以进一步理解这些“Configurable”权限的具体语义资源权限说明AppsCreate允许组内用户在工作区中创建新应用Delete允许组内用户从工作区删除应用Data sourcesCreate允许组内用户在工作区中新增数据源Delete允许组内用户移除工作区中的数据源FolderCreate/Update/Delete允许组内用户创建、更新或删除文件夹以组织资源Workspace constants/variablesCreate/Update/Delete允许组内用户定义、修改或移除工作区范围内使用的常量与变量关于“View”类权限如表中的 Apps View、数据源的使用权限官方明确建议通过Granular Access Control粒度访问控制来配置例如对应用可授予Edit可编辑/构建、View仅查看已发布版本并执行任务或Hide from dashboard从仪表盘隐藏、仅可通过 URL 访问等权限对数据源可授予Configure可查看并编辑数据源配置或Build with可在应用与工作流中基于该数据源创建查询权限。权限配置的默认行为根据 access-control.md 中的一个重要说明如果用户拥有 Create 权限并创建了某个资源该用户自动成为此资源的 owner默认获得与该资源相关的全部权限。例如用户创建数据源 A 后默认就拥有对数据源 A 的 Configure 和 Build with 访问权。这意味着在规划权限时无需为资源创建者额外配置其“自己资源”的访问权。管理用户角色逐步操作指南更新用户角色需要Admin权限。完整步骤如下见 user-roles.md点击仪表盘左下角的设置图标⚙️。进入Workspace settings Users。 示例 URLhttps://app.corp.com/nexus/workspace-settings/users找到需要更新角色的用户点击其所在行末尾的 kebab 菜单⋮ 竖排三点按钮。该菜单在前端由 UsersActionMenu.jsx 实现菜单中包含Edit user details、Reset password允许重置他人密码以及Archive/Unarchive user等操作其中“Edit user details”按钮带有data-cyedit-user-details-button的测试标识点击后通过toggleEditUserDrawer()打开右侧编辑面板。点击Edit user details右侧将弹出编辑面板。在User groups下拉框中更新用户的角色/所属组。点击面板底部的Update按钮。阅读并接受弹出警告点击Continue确认。该用户的角色即更新完成。补充角色变更涉及的工作区权限审计在服务端通过FEATURE_KEY.USER_ROLE_CHANGE等特性键进行控制见 server/src/modules/group-permissions/constants/features.ts并且服务端对“编辑最后一个 Admin 角色”等敏感操作有明确限制见 server/src/modules/group-permissions/constants/error.ts 中的EDITING_LAST_ADMIN_ROLE_NOT_ALLOWED从实现层面防止工作区出现“无主”状态。角色与自定义组的继承与覆盖规则角色不是孤立存在的它与自定义组协同工作。当工作区同时存在默认角色与自定义组时遵循以下规则见 custom-groups.md继承用户继承其分配到的角色以及所属全部自定义组的权限自动升级将用户加入权限高于其当前角色的自定义组时系统会自动将其用户角色升级到与更高访问层级匹配自动移除若用户角色被降级到更低权限系统会自动将其从提供高于新角色权限的自定义组中移除取最高权限当用户属于多个组时取任意组授予的最高权限级别。这一“角色与组联动”的机制在服务端有对应实现。在 server/src/modules/auth/util.service.ts 中可以看到如下注释与逻辑// If any custom group is editable, ensure the role is at least builder - Not considering role mapping可以推断当用户的自定义组包含可编辑类builder 级别权限时系统会确保该用户的角色至少为 builder防止出现“组权限高于角色权限”的矛盾状态——这正是上述“自动升级”规则在代码层面的落地。同时error.ts 中的END_USER_DEFAULT_GROUP_...类错误如“End-user cannot have this builder level permissions”表明服务端会拒绝为 End-user 分配 builder 级权限的非法组合保证角色语义的一致性。实用建议最小权限原则与角色规划结合上述机制在生产环境中规划用户角色时可以参考以下实践先默认角色后自定义组绝大多数成员使用默认角色即可只有需要跨团队、按资源细分访问时才创建自定义组HR、Sales、Finance 等并结合粒度访问控制配置具体应用的 Edit/View 权限。明确 Builder 的“Configurable”边界Builder 的创建/删除权限并非固定Admin 应根据团队职责在Workspace Settings Groups中按需授予或回收参考 access-control.md 的“Configuring Permissions”小节。善用资源 owner 机制既然创建者自动成为资源 owner 并拥有全部相关权限可以将“创建资源”作为授权入口减少事后逐一配置的成本。变更角色时留意自动升级/移除将一个用户移入高权限组会触发角色自动升级反向操作则会自动将其从高权限组移除——这既是便利也是约束变更前应通盘评估影响面。进一步阅读自定义组指南创建、删除、复制自定义组以及继承/覆盖规则的完整说明访问控制指南工作区级权限与粒度访问控制的详细配置权限概念总览User、Group、Permission 三者关系与典型安全场景源码参考USER_ROLE 枚举定义、默认组权限迁移、用户操作菜单实现【免费下载链接】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），仅供参考