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.
BossAgents