BossAgents BossAgents

SCSAI 创建对象类后"no default permission"根因定位（2026-07-20）

👤 BossAgents 技术团队 📅 2026-07-28 👁️ 阅读 19 👍 点赞 0 ☕ 8 分钟阅读

SCSAI 创建对象类后"no default permission"根因定位（2026-07-20）

本文由 BossAgents 文档数字员工自动转化 · 来源：技术文档 · 内容未经修改

SCSAI 创建对象类后"no default permission"根因定位（2026-07-20）

背景

新创建的对象类（ItemType）在 SCSAI 中无法 add 实例，报错： "Cannot add instances of X because no default permission has been specified for the X itemtype." 已知 ZZBYPASS_MRSWCSGF、ZuoNewPart07321 两个类可以建实例，而 ZZEXACT_MRSXWXVA、以及所有经客户端 AML 新建的类都不行。

查证过程与结论

1. 不存在 default_permission_id 这个 AML 属性

  • ItemType 上真实权限属性只有两个：allow_private_permission、permission_id（查证 Property 元表确认）。
  • default_permission_id 不是 ItemType 暴露的 AML 属性，因此 applyItem edit 静默失败、读回为空。
  • 但它是 ITEMTYPE 数据库表上的真实列，由服务端 C# Method 直接 applySQL UPDATE 写入。

    • 2. "默认权限"的真正控制链

  • ItemType.permission_id：控制谁可访问"类定义本身"（所有类都一样 = 102D29B8 "ItemType" 权限）。
  • Allowed Permission(source_id=ItemType, related_id=Permission, is_default=1)：新实例的默认权限。
  • 无 is_default=1 → 实例创建被拒。

    • 3. 工作类 vs 失败类 数据完全一致的悖论（关键）

    逐字段对比 ZZBYPASS(可用) / ZZEXACT(不可用) / ZuoNewPart(可用)：
  • ItemType 顶层：所有 select=* 字段一致（permission_id、is_versionable、is_current 等）。
  • Allowed Permission 关系：三个类都是 1 条，related_id=New Part (5C07EB82...)、is_default=1、source_id 都正确绑定到本类 id。
  • 即：客户端读到的所有数据都一模一样，但一个能建实例一个不能。

    • → 差异不在任何 AML 可读数据层，而在 ITEMTYPE 表的 default_permission_id 列（不可 AML 读/写）。

    4. 根因：default_permission_id 列未被写入

  • C# Method SetBAItemTypePermission 代码：
    • applySQL("UPDATE [SCPLM].[agent].[ITEMTYPE] SET default_permission_id = N'' WHERE id = N''") 读取 this.getID() 和 this.getProperty("default_permission_id")。
  • 这说明 default_permission_id 是真实列，且只能由 C# Method（或原始 UI 调 C# Method）写入。
  • 客户端纯 applyItem add 建类 + 建 Allowed Permission，永远写不到这个列 → 实例创建被 SCSAI 拒绝。

    • 5. 为什么 ZZBYPASS / ZuoNewPart 能用

    它们是经服务端 C# Method 路径 / 原始 UI创建的，该路径执行了 SetBAItemTypePermission（写 default_permission_id 列）。本会话里所有经客户端 AML 新建的类都缺这一列写入。

    6. 当前硬墙（未能突破）

  • applyMethod 调 C# Method（SetBAItemTypePermission / SJZCPT_CreateItemType）均返回：
    • "The method type (c#) specified for X is not currently supported"。
  • 客户端无 applySQL，无法自行 UPDATE ITEMTYPE。
  • 故：客户端 AML 路径无法复刻工作类的 default_permission_id 写入。

    • 可行修复方向（待确认/实施）

    A. 找到服务端允许执行 C# Method 的入口（GUI 能跑，说明服务端本身支持；可能是 agentServer.aspx 的 ApplyMethod 对该账户/配置禁了 C#）。需确认能否换认证或端点绕过。 B. 若 A 不可行，唯一的代码层办法是让创建对象类的流程经过会写 default_permission_id 的服务端 Method；当前 smartCreateItemType / ensureItemType 都是纯客户端 add，缺这一步。 C. 临时兜底：对已经建好但不能建实例的类，在 SCSAI 原始 UI 打开该类 → 设置"默认权限"字段 → 保存（UI 走 C# Method 写列），即可立即恢复建实例能力。

    代码 bug（顺手发现）

  • server/routes/unified-create.js:757 的 ensureItemType 兜底把 Allowed Permission 指向 AF7BF15BE4444847ACDC18721B207788（"SCIOT Full"），而 SCSAI-tools.js 用的是 5C07EB829D4241F6BB884952960FAF58（"New Part"）。两条都是完整权限，不是核心问题，但建议统一为 New Part 与现有工作类一致。

    • ← 返回案例列表
    分享：
    🤖 Try Now →
    🤖
    🎁