ToolJet 访问控制Access Control完全指南从工作区权限到细粒度资源授权【免费下载链接】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体系为应用Apps、数据源Data sources、文件夹Folder与工作区常量/变量Workspace constants/variables提供了一整套可配置的权限模型。本指南以 access-control.md 为核心结合 custom-groups.md、user-roles.md 以及 ToolJet 服务端源码系统讲解两大类权限面向整类资源的基础权限Permissions以及可精确到单个资源的细粒度访问控制Granular Access Control。读完本文你将能独立完成从创建自定义组、勾选资源级权限到按单个应用/数据源做精细化授权与隐藏的完整配置并理解这些配置在底层如何落库与生效。上图展示了工作区设置 Groups 界面左侧为用户角色Admin / Builder / End-user与自定义组列表右侧 Permissions 标签页按资源类型以勾选框形式呈现可配置权限。这是本文所有配置操作的主入口对应文档所述Workspace Settings Groups其访问地址形如https://app.corp.com/nexus/workspace-settings/groups。一、权限模型总览两类权限的分工ToolJet 的访问控制分为两个层次二者互补层次作用对象粒度典型权限配置入口基础权限Permissions整类资源粗粒度Apps Create/Delete、Data sources Create/Delete 等Groups 详情 Permissions标签页细粒度访问控制Granular Access Control单个/部分资源细粒度单个 App 的 Edit/View/Hide、单个数据源的 Configure/Build withGroups 详情 Granular access标签页两者叠加使用基础权限决定某类资源能否被创建/删除细粒度权限决定某个具体资源谁能看、谁能改、谁能用。文档明确指出要配置视图或编辑访问需要进入Granular Access Control一节。在源码层面这两类权限由两套实体承载。基础权限对应permission_groups表group_permissions.entity.ts其中的appCreate、appDelete、dataSourceCreate、dataSourceDelete、folderCreate、folderDelete、orgConstantCRUD等布尔列正是 UI 中勾选框的落库字段细粒度权限则由granular_permissions表granular_permissions.entity.ts及其关联的apps_group_permissions、data_sources_group_permissions、group_apps、group_data_sources等表承载。下文将逐一展开。二、基础权限Permissions2.1 权限项速查表以下权限可在对应资源上为组配置取自原文档并补充了 UI 中的实际描述文本资源权限说明AppsCreate允许组成员在工作区内创建新应用Delete允许组成员从工作区删除应用Data sourcesCreate允许组成员在工作区添加新数据源Delete允许组成员从工作区移除数据源FolderCreate/Update/Delete允许组成员创建、更新或删除文件夹以组织资源Workspace constants/variablesCreate/Update/Delete允许组成员定义、修改或移除跨工作区使用的常量与变量这些权限直接映射到 group_permissions.entity.ts 中的数据库列appCreate/appDelete、dataSourceCreate/dataSourceDelete、folderCreate/folderDelete文件夹的 Create/Update/Delete 合并为对文件夹的所有操作、orgConstantCRUD工作区常量/变量的完整增删改。从实体定义可以推断还包括workflowCreate/workflowDelete、moduleCreate/moduleDelete、tjdbCRUDToolJet Database 读写、appPromote/appRelease等更多能力位它们共同组成一个组的权限位图。2.2 所有者语义创建者即默认所有者:::info 如果用户拥有 create 权限并创建了一个资源该用户即成为该资源的所有者默认拥有与之相关的全部权限。例如用户创建了数据源 A则默认拥有数据源 A 的 configure 与 build 访问权限。 :::这条规则保证了谁创建、谁负责的直观语义即使细粒度权限尚未显式配置创建者也不会被自己创建的资源锁在门外。2.3 配置基础权限的操作步骤所需角色Admin点击仪表盘左下角的设置图标⚙️。进入Workspace SettingsGroups示例 URLhttps://app.corp.com/nexus/workspace-settings/groups。选择要配置权限的组。切换到Permissions标签页勾选所需的权限项即可生效见上文select-permission.png截图Apps 的 Create、Data sources 的 Create、Folder 与 Workspace constants/variables 均已勾选。默认角色与这些权限的关系详见 user-roles.mdAdmin 拥有全部工作区级权限Builder 的各项权限可配置ConfigurableEnd-user 只能查看和使用被授予访问权的已发布应用。这一规则在 constants/index.ts 的DEFAULT_GROUP_PERMISSIONS中固化Admin 与 Builder 的appCreate、dataSourceCreate、folderCreate、orgConstantCRUD等均为true而 End-user 全部为false。三、细粒度访问控制Granular Access Control细粒度访问控制允许对应用和数据源分别配置视图访问或编辑访问等权限管理谁能与工作区中的哪些资源交互。权限既可以应用到全部资源如所有应用或所有数据源也可以应用到特定选中的资源兼顾灵活性与精确性。配置细粒度访问控制的前提是创建自定义组请参照 custom-groups.md 的指引其典型场景是为 HR 与 Sales 两个团队各建一个自定义组再通过细粒度权限分别为两组勾选各自的应用。3.1 应用Apps的细粒度权限权限说明适用人群Edit对选中的应用授予编辑访问权用户可构建或编辑被授权的应用Builder / 开发者View用户可查看所选应用的已发布版本并使用其完成任务但不能编辑或更改End-user / 消费者Hide from dashboard将所选应用从仪表盘隐藏仅对有 view 权限的用户通过 URL 访问有 edit 权限的用户始终能在仪表盘看到该应用用于内部工具、未发布或敏感应用All apps将所选访问权Edit 或 View授予工作区内所有应用包括未来新建的应用全量授权的团队Custom仅将所选访问权Edit 或 View授予指定的应用需要精确圈定应用集合的场景上图即Add apps permissions弹窗Permission 区在Edit说明 Access to app builder与View说明 Only access released version of apps之间单选勾选Hide from dashboard后应用将 accessible by URL onlyResources 区在All apps含新建应用与Custom手动挑选应用之间单选。3.2 数据源Data sources的细粒度权限权限说明适用人群Configure组内用户可访问并编辑所选数据源的配置详情Admin 等需要配置数据源的人员Build with组内用户可在应用与工作流中使用所选数据源创建查询Builder / 开发者All data sources将所选访问权Configure 或 Build with授予工作区内所有数据源包括新建的数据源全量授权场景Custom仅将所选访问权授予指定的数据源精确圈定数据源集合的场景Add data sources permissions弹窗结构与应用弹窗对称ConfigureAccess and edit connection detail与Build withUse in apps workflows单选Resources 区在All data sources含新建连接与Custom之间单选。3.3 配置细粒度访问权限的操作步骤所需角色Admin点击仪表盘左下角的设置图标⚙️。进入Workspace SettingsGroups示例 URLhttps://app.corp.com/nexus/workspace-settings/groups。选择要配置细粒度访问权限的组。切换到Granular access标签页点击 Add permission按钮。按需选择资源类型Apps / Data source为权限命名配置所需权限点击弹窗底部的Add完成创建。如上图所示在组的Granular access标签页中通过 Add permission 按钮弹出的选择器可快速切换Apps或Data source两种资源类型进入对应的权限配置弹窗。3.4 源码视角细粒度权限如何落库细粒度权限在服务端由一组 TypeORM 实体支撑配置弹窗中的每个选项都能在数据库列中找到对应granular_permissions.entity.ts主表granular_permissions记录一条授权条目的groupId、name权限名称、type资源类型枚举见 constants/index.ts 的ResourceTypeapp、data_source、workflow、folder、module等以及isAll是否作用于全部资源默认true。它与apps_group_permissions、data_sources_group_permissions、folders_group_permissions均为 OneToOne 级联删除关系。apps_group_permissions.entity.ts承载应用授权细节canEdit对应 UI 的 Edit、canView对应 View、hideFromDashboard对应 Hide from dashboard以及canAccessDevelopment/canAccessStaging/canAccessProduction/canAccessReleased四个环境访问位默认均为true即默认放开对开发、暂存、生产与已发布版本的访问。这也解释了 UI 上 Edit/View 与 Hide 为何是并列可勾选的关系。group_apps.entity.ts通过(appId, appsGroupPermissionsId)唯一约束把授权条目与实际应用一一关联——当 Resources 选择Custom时选中的应用即写入此表选择All apps时isAll置真、无需逐条列举。data_sources_group_permissions.entity.ts承载数据源授权canConfigure对应 Configure、canUse对应 Build with、canRunQuery默认true允许运行查询。group_data_source.entity.ts通过(dataSourceId, dataSourcesGroupPermissionsId)关联授权条目与具体数据源是 Custom 模式下数据源选择结果的落库位置。此外默认角色各自拥有一套资源级默认权限定义于 constants/index.ts 的DEFAULT_RESOURCE_PERMISSIONS例如 Admin 对 App 默认canEdit: true、对数据源默认canConfigure: true且可访问全部四个环境End-user 对 App 默认canView: true、canAccessDevelopment/Staging/Production均为false而canAccessReleased: true——与最终用户只能使用已发布版本的文档描述完全一致。四、与自定义组、用户角色的协作细粒度访问控制的载体是自定义组。结合 custom-groups.mdAdmin 可完成以下组管理操作创建自定义组Groups 页点击 Create new group输入名称并确认。组的类型在数据库中记为CUSTOM_GROUP custom与内置的DEFAULT类型区分见 constants/index.ts。删除自定义组通过组行尾的 kebab 菜单选择Delete并在弹窗中确认。复制组Duplicate通过 kebab 菜单选择Duplicate挑选要复制的组成部分即可基于现有组快速复制权限结构。角色与组之间的继承与覆盖规则同样来自 custom-groups 文档是理解权限判定结果的关键用户从其分配的角色以及所属的任何自定义组继承权限将用户加入权限高于其当前角色的自定义组会自动将用户角色升级到更高的访问级别若用户角色被降级到较低权限用户会自动被移出任何提供了超出其新角色权限的自定义组当用户属于多个组时取任一组的最高权限生效。这四条规则与 user-roles.md 中的三种默认角色Admin、Builder、End-user相互配合Admin 全权管理Builder 创建与配置应用End-user 消费已发布应用。例如一个 HR 团队自定义组被授予了某应用的 Edit 权限那么组内即使包含 End-user也会因取最高权限规则而获得编辑能力同时其角色会被自动升级为 Builder——这正是升权自动升级、降权自动移出机制的目的所在。五、最佳实践与常见误区基于上述权限模型与源码结构给出以下实操建议按团队建组、按资源圈定将谁拥有什么角色与谁能访问哪些具体资源解耦——角色通过 user-roles.md 管理资源访问通过自定义组 细粒度权限管理。HR/Sales 分组的例子即是标准范式。优先使用 All apps / All data sources 保障可扩展性当团队会持续新增应用或数据源且都应可见时选择All appsisAll true可让新建资源自动纳入授权范围避免逐一手动添加反之仅需固定集合时应选Custom以收紧暴露面。善用 Hide from dashboard 但不滥用该选项只对 view 权限生效编辑者始终可见适合将敏感或测试中的应用藏到 URL 直达之后但要注意被隐藏应用对 end-user 依然可通过链接访问需配合工作区安全策略使用。记住创建者即所有者赋予组 Create 权限意味着组内用户创建的资源自动归其所有因此对 Create 权限的授予应与资源归属策略同步考虑。留意环境访问位应用级授权还包含 Development / Staging / Production / Released 四个环境访问位默认全开。若需要限制组员只能在开发环境编辑、不能触碰生产数据可在对应列上收紧见 apps_group_permissions.entity.ts。六、进一步阅读权限配置入口与组管理custom-groups.md三种默认角色及其权限矩阵user-roles.md权限位图实体permission_groups表定义于 group_permissions.entity.ts细粒度授权实体granular_permissions及其关联表定义于 granular_permissions.entity.ts、apps_group_permissions.entity.ts、data_sources_group_permissions.entity.ts、group_apps.entity.ts、group_data_source.entity.ts默认角色与默认资源权限的固化配置constants/index.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），仅供参考
ToolJet 访问控制（Access Control）完全指南：从工作区权限到细粒度资源授权
ToolJet 访问控制Access Control完全指南从工作区权限到细粒度资源授权【免费下载链接】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体系为应用Apps、数据源Data sources、文件夹Folder与工作区常量/变量Workspace constants/variables提供了一整套可配置的权限模型。本指南以 access-control.md 为核心结合 custom-groups.md、user-roles.md 以及 ToolJet 服务端源码系统讲解两大类权限面向整类资源的基础权限Permissions以及可精确到单个资源的细粒度访问控制Granular Access Control。读完本文你将能独立完成从创建自定义组、勾选资源级权限到按单个应用/数据源做精细化授权与隐藏的完整配置并理解这些配置在底层如何落库与生效。上图展示了工作区设置 Groups 界面左侧为用户角色Admin / Builder / End-user与自定义组列表右侧 Permissions 标签页按资源类型以勾选框形式呈现可配置权限。这是本文所有配置操作的主入口对应文档所述Workspace Settings Groups其访问地址形如https://app.corp.com/nexus/workspace-settings/groups。一、权限模型总览两类权限的分工ToolJet 的访问控制分为两个层次二者互补层次作用对象粒度典型权限配置入口基础权限Permissions整类资源粗粒度Apps Create/Delete、Data sources Create/Delete 等Groups 详情 Permissions标签页细粒度访问控制Granular Access Control单个/部分资源细粒度单个 App 的 Edit/View/Hide、单个数据源的 Configure/Build withGroups 详情 Granular access标签页两者叠加使用基础权限决定某类资源能否被创建/删除细粒度权限决定某个具体资源谁能看、谁能改、谁能用。文档明确指出要配置视图或编辑访问需要进入Granular Access Control一节。在源码层面这两类权限由两套实体承载。基础权限对应permission_groups表group_permissions.entity.ts其中的appCreate、appDelete、dataSourceCreate、dataSourceDelete、folderCreate、folderDelete、orgConstantCRUD等布尔列正是 UI 中勾选框的落库字段细粒度权限则由granular_permissions表granular_permissions.entity.ts及其关联的apps_group_permissions、data_sources_group_permissions、group_apps、group_data_sources等表承载。下文将逐一展开。二、基础权限Permissions2.1 权限项速查表以下权限可在对应资源上为组配置取自原文档并补充了 UI 中的实际描述文本资源权限说明AppsCreate允许组成员在工作区内创建新应用Delete允许组成员从工作区删除应用Data sourcesCreate允许组成员在工作区添加新数据源Delete允许组成员从工作区移除数据源FolderCreate/Update/Delete允许组成员创建、更新或删除文件夹以组织资源Workspace constants/variablesCreate/Update/Delete允许组成员定义、修改或移除跨工作区使用的常量与变量这些权限直接映射到 group_permissions.entity.ts 中的数据库列appCreate/appDelete、dataSourceCreate/dataSourceDelete、folderCreate/folderDelete文件夹的 Create/Update/Delete 合并为对文件夹的所有操作、orgConstantCRUD工作区常量/变量的完整增删改。从实体定义可以推断还包括workflowCreate/workflowDelete、moduleCreate/moduleDelete、tjdbCRUDToolJet Database 读写、appPromote/appRelease等更多能力位它们共同组成一个组的权限位图。2.2 所有者语义创建者即默认所有者:::info 如果用户拥有 create 权限并创建了一个资源该用户即成为该资源的所有者默认拥有与之相关的全部权限。例如用户创建了数据源 A则默认拥有数据源 A 的 configure 与 build 访问权限。 :::这条规则保证了谁创建、谁负责的直观语义即使细粒度权限尚未显式配置创建者也不会被自己创建的资源锁在门外。2.3 配置基础权限的操作步骤所需角色Admin点击仪表盘左下角的设置图标⚙️。进入Workspace SettingsGroups示例 URLhttps://app.corp.com/nexus/workspace-settings/groups。选择要配置权限的组。切换到Permissions标签页勾选所需的权限项即可生效见上文select-permission.png截图Apps 的 Create、Data sources 的 Create、Folder 与 Workspace constants/variables 均已勾选。默认角色与这些权限的关系详见 user-roles.mdAdmin 拥有全部工作区级权限Builder 的各项权限可配置ConfigurableEnd-user 只能查看和使用被授予访问权的已发布应用。这一规则在 constants/index.ts 的DEFAULT_GROUP_PERMISSIONS中固化Admin 与 Builder 的appCreate、dataSourceCreate、folderCreate、orgConstantCRUD等均为true而 End-user 全部为false。三、细粒度访问控制Granular Access Control细粒度访问控制允许对应用和数据源分别配置视图访问或编辑访问等权限管理谁能与工作区中的哪些资源交互。权限既可以应用到全部资源如所有应用或所有数据源也可以应用到特定选中的资源兼顾灵活性与精确性。配置细粒度访问控制的前提是创建自定义组请参照 custom-groups.md 的指引其典型场景是为 HR 与 Sales 两个团队各建一个自定义组再通过细粒度权限分别为两组勾选各自的应用。3.1 应用Apps的细粒度权限权限说明适用人群Edit对选中的应用授予编辑访问权用户可构建或编辑被授权的应用Builder / 开发者View用户可查看所选应用的已发布版本并使用其完成任务但不能编辑或更改End-user / 消费者Hide from dashboard将所选应用从仪表盘隐藏仅对有 view 权限的用户通过 URL 访问有 edit 权限的用户始终能在仪表盘看到该应用用于内部工具、未发布或敏感应用All apps将所选访问权Edit 或 View授予工作区内所有应用包括未来新建的应用全量授权的团队Custom仅将所选访问权Edit 或 View授予指定的应用需要精确圈定应用集合的场景上图即Add apps permissions弹窗Permission 区在Edit说明 Access to app builder与View说明 Only access released version of apps之间单选勾选Hide from dashboard后应用将 accessible by URL onlyResources 区在All apps含新建应用与Custom手动挑选应用之间单选。3.2 数据源Data sources的细粒度权限权限说明适用人群Configure组内用户可访问并编辑所选数据源的配置详情Admin 等需要配置数据源的人员Build with组内用户可在应用与工作流中使用所选数据源创建查询Builder / 开发者All data sources将所选访问权Configure 或 Build with授予工作区内所有数据源包括新建的数据源全量授权场景Custom仅将所选访问权授予指定的数据源精确圈定数据源集合的场景Add data sources permissions弹窗结构与应用弹窗对称ConfigureAccess and edit connection detail与Build withUse in apps workflows单选Resources 区在All data sources含新建连接与Custom之间单选。3.3 配置细粒度访问权限的操作步骤所需角色Admin点击仪表盘左下角的设置图标⚙️。进入Workspace SettingsGroups示例 URLhttps://app.corp.com/nexus/workspace-settings/groups。选择要配置细粒度访问权限的组。切换到Granular access标签页点击 Add permission按钮。按需选择资源类型Apps / Data source为权限命名配置所需权限点击弹窗底部的Add完成创建。如上图所示在组的Granular access标签页中通过 Add permission 按钮弹出的选择器可快速切换Apps或Data source两种资源类型进入对应的权限配置弹窗。3.4 源码视角细粒度权限如何落库细粒度权限在服务端由一组 TypeORM 实体支撑配置弹窗中的每个选项都能在数据库列中找到对应granular_permissions.entity.ts主表granular_permissions记录一条授权条目的groupId、name权限名称、type资源类型枚举见 constants/index.ts 的ResourceTypeapp、data_source、workflow、folder、module等以及isAll是否作用于全部资源默认true。它与apps_group_permissions、data_sources_group_permissions、folders_group_permissions均为 OneToOne 级联删除关系。apps_group_permissions.entity.ts承载应用授权细节canEdit对应 UI 的 Edit、canView对应 View、hideFromDashboard对应 Hide from dashboard以及canAccessDevelopment/canAccessStaging/canAccessProduction/canAccessReleased四个环境访问位默认均为true即默认放开对开发、暂存、生产与已发布版本的访问。这也解释了 UI 上 Edit/View 与 Hide 为何是并列可勾选的关系。group_apps.entity.ts通过(appId, appsGroupPermissionsId)唯一约束把授权条目与实际应用一一关联——当 Resources 选择Custom时选中的应用即写入此表选择All apps时isAll置真、无需逐条列举。data_sources_group_permissions.entity.ts承载数据源授权canConfigure对应 Configure、canUse对应 Build with、canRunQuery默认true允许运行查询。group_data_source.entity.ts通过(dataSourceId, dataSourcesGroupPermissionsId)关联授权条目与具体数据源是 Custom 模式下数据源选择结果的落库位置。此外默认角色各自拥有一套资源级默认权限定义于 constants/index.ts 的DEFAULT_RESOURCE_PERMISSIONS例如 Admin 对 App 默认canEdit: true、对数据源默认canConfigure: true且可访问全部四个环境End-user 对 App 默认canView: true、canAccessDevelopment/Staging/Production均为false而canAccessReleased: true——与最终用户只能使用已发布版本的文档描述完全一致。四、与自定义组、用户角色的协作细粒度访问控制的载体是自定义组。结合 custom-groups.mdAdmin 可完成以下组管理操作创建自定义组Groups 页点击 Create new group输入名称并确认。组的类型在数据库中记为CUSTOM_GROUP custom与内置的DEFAULT类型区分见 constants/index.ts。删除自定义组通过组行尾的 kebab 菜单选择Delete并在弹窗中确认。复制组Duplicate通过 kebab 菜单选择Duplicate挑选要复制的组成部分即可基于现有组快速复制权限结构。角色与组之间的继承与覆盖规则同样来自 custom-groups 文档是理解权限判定结果的关键用户从其分配的角色以及所属的任何自定义组继承权限将用户加入权限高于其当前角色的自定义组会自动将用户角色升级到更高的访问级别若用户角色被降级到较低权限用户会自动被移出任何提供了超出其新角色权限的自定义组当用户属于多个组时取任一组的最高权限生效。这四条规则与 user-roles.md 中的三种默认角色Admin、Builder、End-user相互配合Admin 全权管理Builder 创建与配置应用End-user 消费已发布应用。例如一个 HR 团队自定义组被授予了某应用的 Edit 权限那么组内即使包含 End-user也会因取最高权限规则而获得编辑能力同时其角色会被自动升级为 Builder——这正是升权自动升级、降权自动移出机制的目的所在。五、最佳实践与常见误区基于上述权限模型与源码结构给出以下实操建议按团队建组、按资源圈定将谁拥有什么角色与谁能访问哪些具体资源解耦——角色通过 user-roles.md 管理资源访问通过自定义组 细粒度权限管理。HR/Sales 分组的例子即是标准范式。优先使用 All apps / All data sources 保障可扩展性当团队会持续新增应用或数据源且都应可见时选择All appsisAll true可让新建资源自动纳入授权范围避免逐一手动添加反之仅需固定集合时应选Custom以收紧暴露面。善用 Hide from dashboard 但不滥用该选项只对 view 权限生效编辑者始终可见适合将敏感或测试中的应用藏到 URL 直达之后但要注意被隐藏应用对 end-user 依然可通过链接访问需配合工作区安全策略使用。记住创建者即所有者赋予组 Create 权限意味着组内用户创建的资源自动归其所有因此对 Create 权限的授予应与资源归属策略同步考虑。留意环境访问位应用级授权还包含 Development / Staging / Production / Released 四个环境访问位默认全开。若需要限制组员只能在开发环境编辑、不能触碰生产数据可在对应列上收紧见 apps_group_permissions.entity.ts。六、进一步阅读权限配置入口与组管理custom-groups.md三种默认角色及其权限矩阵user-roles.md权限位图实体permission_groups表定义于 group_permissions.entity.ts细粒度授权实体granular_permissions及其关联表定义于 granular_permissions.entity.ts、apps_group_permissions.entity.ts、data_sources_group_permissions.entity.ts、group_apps.entity.ts、group_data_source.entity.ts默认角色与默认资源权限的固化配置constants/index.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），仅供参考