ToolJet 工作流权限详解Admins、App 编辑组与终端用户的三级访问控制【免费下载链接】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工作流Workflows是 ToolJet 中用于编排自动化逻辑的核心能力而权限体系决定了谁能查看、编辑和执行这些工作流。本文以 docs/docs/workflows/permissions.md 为主体结合 ToolJet 开源仓库的服务端权限实现完整梳理工作流权限的三种用户角色Admins、Groups with App Editing Permissions、End Users各自的能力边界并深入到 CASL 能力模型与默认用户组常量帮助你精确配置内部工具、仪表盘和业务应用中的工作流访问控制。工作流权限总览在 ToolJet Workflows 中权限管理遵循结构化、可精确到单个动作的设计思路谁可以查看、编辑或执行工作流都通过统一的权限模型来约束。下面这张表给出了工作流权限的完整摘要它同时也是本文后续三个章节的索引用户组工作流仪表盘访问创建/编辑工作流执行工作流在 ToolJet App Builder 中使用工作流启用/禁用工作流Admins✅✅✅✅✅具有 App 编辑权限的组Groups with App Editing Permissions❌❌✅✅❌终端用户End Users❌❌✅❌❌从表中可以清晰看到权限的三层递进结构Admins拥有全量权限是唯一能够进入工作流仪表盘、创建/编辑工作流以及启用或禁用工作流执行的群体具有 App 编辑权限的组属于构建者定位能复用已有工作流来搭建应用但不能修改工作流本身终端用户仅能在应用内触发工作流执行属于纯消费方。Admins工作流的全权管理者Admins可以创建、编辑和管理工作流能够访问工作流仪表盘Workflow Dashboard与流程构建器Flow Builder并且可以在 ToolJet 的App Builder中使用这些工作流。此外他们还可以使用工作流编辑页面右上角的Enable开关在 ToolJet 应用中启用或禁用工作流的执行——这是控制工作流是否对外生效的总闸门。这一能力在服务端源码中有着直接的对应实现。在 server/src/modules/group-permissions/constants/index.ts 中DEFAULT_GROUP_PERMISSIONS为默认的ADMIN用户组预置了workflowCreate: true与workflowDelete: true同时isBuilderLevel: true表明该组处于构建者级别而在DEFAULT_RESOURCE_PERMISSIONS中USER_ROLE.ADMIN对ResourceType.WORKFLOWS资源持有canEdit: true意味着管理员对所有工作流资源都具备编辑能力。更底层的判定逻辑位于 server/src/modules/apps/ability/workflow.ability.ts 的defineWorkflowAbility函数中。当isAdmin || superAdmin为真时CASL 能力构建器会一次性授予工作流相关的全部FEATURE_KEY包括CREATE、UPDATE、DELETE、GET_ONE、GET_BY_SLUG、RELEASE、VALIDATE_PRIVATE_APP_ACCESS、VALIDATE_RELEASED_APP_ACCESS与UPDATE_ICONif (isAdmin || superAdmin) { // Admin or super admin can do all operations can( [ FEATURE_KEY.CREATE, FEATURE_KEY.UPDATE, FEATURE_KEY.DELETE, FEATURE_KEY.GET_ONE, FEATURE_KEY.GET_BY_SLUG, FEATURE_KEY.RELEASE, FEATURE_KEY.VALIDATE_PRIVATE_APP_ACCESS, FEATURE_KEY.VALIDATE_RELEASED_APP_ACCESS, FEATURE_KEY.UPDATE_ICON, ], App ); return; }从源码结构看ToolJet 中的工作流在数据模型上对应type workflow的 AppVersion见 server/src/modules/workflows/guards/workflow-access.guard.ts因此管理员对工作流执行UPDATE、RELEASE发布等操作实际走的也是统一的 CASL 授权通道。此外数据迁移 server/data-migrations/1754999194042-UpdateWorkflowPermissionsForAdminAndBuilder.ts 与 server/data-migrations/1758009004418-AddWorkflowGranularPermissionsToExistingAdminGroups.ts 进一步印证工作流权限会随版本演进被回填到既有管理组保证历史工作区与新增权限模型保持一致。Groups with App Editing Permissions复用工作流但不能修改具有 App 编辑权限的组Groups with App Editing Permissions可以在 ToolJet 的App Builder中使用已有的工作流将其接入应用交互但无法像 Admins 一样创建或修改工作流本身。典型场景示例假设一家公司使用 ToolJet 构建内部应用HR 部门希望集成一条员工请假申请获批后自动发送邮件的新工作流。作为具有 App 编辑权限的组的成员可以完成以下操作在 App Builder 界面中添加一个名为Approve Leave批准请假的按钮将该按钮链接到一条已有的、用于发送自动邮件的现有工作流使用另一条提供相关数据的工作流设计一张展示每月获准请假数量的图表。也就是说这类用户能够驾驭现有工作流并将其整合进应用功能但无法像 Admins 那样亲自创建或修改工作流。源码视角的印证在 server/src/modules/group-permissions/constants/index.ts 的DEFAULT_RESOURCE_PERMISSIONS中USER_ROLE.BUILDER对ResourceType.WORKFLOWS同样持有canEdit: true且DEFAULT_GROUP_PERMISSIONS.BUILDER同样开启了workflowCreate与workflowDelete——这说明具有 App 编辑权限的组通常与默认 Builder 组同属构建者级别。而对于被显式限制为仅可编辑应用、不可编辑工作流的自定义组workflow.ability.ts中的逻辑会精确收敛其能力当userWorkflowPermissions.editableWorkflowsId列表不含当前workflowId时UPDATE、GET_ONE、RELEASE等编辑类能力均不会被授予只有FEATURE_KEY.CREATE在isAllWorkflowsCreatable对应userPermission?.workflowCreate为真时才放开。这意味着从能力模型层面工作流的可编辑与可执行是两套独立判定的维度可以被细粒度拆开配置。End Users仅执行不接触构建终端用户End Users只能在工作流所在的应用程序中执行工作流无法访问工作流仪表盘也无法在 App Builder 中使用或修改工作流。典型场景示例沿用上面的公司场景一名来自销售部门的员工终端用户登录 ToolJet 构建的内部应用申请年假其完整交互链路如下员工填写Leave Request请假申请表单提交后点击Request Leave申请请假按钮——该按钮链接到一条将申请发送至 HR 部门的工作流当 HR 使用Approve Leave按钮由具有 App 编辑权限的组创建批准请假后员工会收到一封自动邮件通知该通知由另一条工作流触发。在这条链路中终端用户全程只扮演触发者角色他们发起的是工作流的执行而非工作流的构建或管理。源码视角的印证DEFAULT_GROUP_PERMISSIONS.END_USER中workflowCreate: false、workflowDelete: false且isBuilderLevel: falseDEFAULT_RESOURCE_PERMISSIONS[USER_ROLE.END_USER][ResourceType.WORKFLOWS]为canEdit: false, canView: true。这与权限表中的❌ 创建/编辑、✅ 执行完全吻合。在defineWorkflowAbility中终端用户对应的分支是执行级授权if ( isAllWorkflowsExecutable || (userWorkflowPermissions?.executableWorkflowsId?.length workflowId userWorkflowPermissions.executableWorkflowsId.includes(workflowId)) ) { // add view permissions for all workflows or specific workflow can([FEATURE_KEY.GET_ONE, FEATURE_KEY.GET_BY_SLUG, FEATURE_KEY.VALIDATE_RELEASED_APP_ACCESS], App); }可以看到当用户仅持有执行权限时只会被授予GET_ONE、GET_BY_SLUG与VALIDATE_RELEASED_APP_ACCESS这类读取 校验已发布应用访问权的能力——这正是能触发执行、但拿不到任何编辑能力的底层保证。而真正拦截越权请求的是 server/src/modules/workflows/guards/workflow-access.guard.ts 中的WorkflowAccessGuard它会校验appVersionId的 UUID 格式、当前用户是否已认证并确认该版本确实对应一个type workflow的应用版本随后将解析出的工作流挂载到请求上下文供后续控制器与能力判定使用。从用户组到执行权限的落地链路综合以上源码可以梳理出 ToolJet 工作流权限从配置到生效的完整链路定义层默认用户组Admin / Builder / End User的权限模板集中在 server/src/modules/group-permissions/constants/index.ts通过workflowCreate、workflowDelete与ResourceType.WORKFLOWS上的canEdit/canView决定组的初始能力判定层server/src/modules/apps/ability/workflow.ability.ts 的defineWorkflowAbility基于 CASL 构建当前用户的能力集区分全部可编辑/可执行与按 workflow ID 白名单可编辑/可执行两种模式管理员直接走全量授权分支执行层工作流相关请求经 server/src/modules/workflows/guards/workflow-access.guard.ts 验证资源类型与身份再由控制器server/src/modules/workflows/controllers/workflows.controller.ts、workflow-executions.controller.ts 等依据能力模型放行或拒绝管理面Admins 通过编辑器右上角的Enable开关控制工作流在应用中的执行开关这一启用/禁用能力仅授予管理员层级与权限表中的最后一列一一对应。实战建议按最小权限分配默认情况下只把 Builder 或同等构建者角色授予需要编排工作流的成员仅需在应用内复用工作流的成员应归入具有 App 编辑权限的组而最终使用者一律以 End User 身份登录善用 Enable 开关在灰度或故障期间Admins 可以暂时禁用某条工作流的执行而不影响其在 App Builder 中的引用与后续再次启用理解可执行与可编辑的独立性从workflow.ability.ts可以看到执行权限executableWorkflowsId与编辑权限editableWorkflowsId是独立的判定维度若你的工作区启用了细粒度工作流权限可以按工作流 ID 精确放行执行权而不授予任何编辑权版本升级注意回填迁移仓库中的相关数据迁移如 1754999194042-UpdateWorkflowPermissionsForAdminAndBuilder.ts会自动为既有管理组补齐新增的工作流权限升级后建议抽查一次默认组的权限模板确保与预期一致。【免费下载链接】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），仅供参考