SCSAI Root Cause Analysis of "No Default Permission" After Creating Object…

SCSAI Root Cause Analysis of "No Default Permission" After Creating Object Class (2026-07-20)

Background

Newly created object classes (ItemType) in SCSAI cannot add instances, with the error:

"Cannot add instances of X because no default permission has been specified for the X itemtype."

It is known that two classes, ZZBYPASS_MRSWCSGF and ZuoNewPart07321, can create instances, while ZZEXACT_MRSXWXVA and all classes created via the client AML cannot.

Investigation Process and Conclusion

1. The default_permission_id AML attribute does not exist.

  • The ItemType has only two real permission attributes: allow_private_permission and permission_id (confirmed by checking the Property metadata table).
  • default_permission_id is not an AML attribute exposed by ItemType, so the applyItem edit fails silently and returns empty when read back.
  • However, it is a real column in the ITEMTYPE database table, written directly by the server-side C# Method via applySQL UPDATE.

2. The actual control chain for "Default Permission"

  • ItemType.permission_id: Controls who can access the "class definition itself" (same for all classes = 102D29B8 "ItemType" permission).
  • Allowed Permission (source_id=ItemType, related_id=Permission, is_default=1): Default permission for new instances.
  • No is_default=1 → Instance creation is rejected.

3. The paradox of identical data between working class and failure class (critical)

Field-by-field comparison of ZZBYPASS (usable) / ZZEXACT (unusable) / ZuoNewPart (usable):

  • ItemType top-level: All select=* fields are identical (permission_id, is_versionable, is_current, etc.).
  • Allowed Permission relationship: All three classes have 1 entry, related_id=New Part (5C07EB82...), is_default=1, source_id correctly bound to the respective class id.
  • That is: All data read by the client is exactly the same, yet one can create instances and the other cannot.

→ The difference is not in any AML-readable data layer, but in the default_permission_id column of the ITEMTYPE table (not AML readable/writable).

4. Root cause: The default_permission_id column was not written.

  • C# Method SetBAItemTypePermission code:

applySQL("UPDATE [SCPLM].[agent].[ITEMTYPE] SET default_permission_id = N'' WHERE id = N''")

Read this.getID() and this.getProperty("default_permission_id").

  • This indicates that default_permission_id is a real column and can only be written by a C# Method (or by the original UI calling a C# Method).
  • Pure client-side applyItem add for creating a class + creating an Allowed Permission can never write to this column → instance creation is rejected by SCSAI.

5. Why ZZBYPASS / ZuoNewPart works

They were created via the server-side C# Method path / original UI, which executes SetBAItemTypePermission (writing the default_permission_id column). All classes created via client-side AML in this session lack this column write.

6. Current hard barrier (not yet overcome)

  • applyMethod calls to C# Methods (SetBAItemTypePermission / SJZCPT_CreateItemType) both return:

"The method type (c#) specified for X is not currently supported".

  • The client has no applySQL and cannot perform UPDATE ITEMTYPE on its own.
  • Therefore: The client-side AML path cannot replicate the default_permission_id write for the working class.

Feasible Fix Directions (To Be Confirmed/Implemented)

A. Find the server-side entry point that allows execution of C# Methods (the GUI can run, indicating the server inherently supports it; it might be that agentServer.aspx's ApplyMethod has disabled C# for this account/configuration). Need to confirm if authentication or endpoint can be bypassed.

B. If A is not feasible, the only code-level solution is to make the process of creating object classes go through a server-side Method that writes default_permission_id; currently smartCreateItemType / ensureItemType are purely client-side adds, missing this step.

C. Temporary workaround: For already created classes that cannot create instances, open the class in the original SCSAI UI → set the "Default Permission" field → save (the UI uses a C# Method to write the column), which immediately restores the ability to create instances.

Code Bug (Incidentally Discovered)

  • The ensureItemType fallback at server/routes/unified-create.js:757 points Allowed Permission to AF7BF15BE4444847ACDC18721B207788 ("SCIOT Full"), while SCSAI-tools.js uses 5C07EB829D4241F6BB884952960FAF58 ("New Part"). Both are full permissions, not a core issue, but it's recommended to unify them to New Part for consistency with existing work classes.
← 返回案例列表

Try 左帮右臂 Industrial Agent — your digital workforce

Available as a WeChat mini program, web app (ylxt.chat) and desktop client. Start from whichever fits your workflow.

🌐 Web App 💻 Desktop Download 📞 Call 189-8606-6876
WeChat mini program QR
Scan for the WeChat mini program
Share:
🤖 Try Now →
🤖
🎁