CAD file check-in fails with permission denied error in specification management workflow

PLM Windchill
, , , , , , , ,
1

We’re experiencing consistent failures when users attempt to check in CAD files to specification containers. The error occurs specifically with ACL inheritance configuration in our multi-level container structure.

The AccessDeniedException appears even for users with proper role-based access control assignments at the parent container level. We’ve verified container-level permissions are correctly configured, but the inheritance chain seems broken.


wt.access.AccessDeniedException: User lacks MODIFY permission
at wt.folder.FolderHelper.checkAccess(FolderHelper.java:234)
at wt.epm.EPMDocument.checkin(EPMDocument.java:156)

This is blocking specification management workflows entirely. Has anyone dealt with permission cache rebuild requirements after container restructuring?

2

I’ve seen this exact scenario. The issue is typically that ACL inheritance doesn’t automatically propagate when you restructure containers. The permission cache holds stale references to the old hierarchy. You need to explicitly trigger a rebuild after any container-level permission changes. Check if your specification containers have the ‘Inherit ACL’ flag properly set in the container properties.

3

Check your site.xconf settings for permission caching. We had an issue where the cache timeout was set too high, causing permission changes to not take effect for hours. Also verify that your method server is properly configured to handle ACL updates. Sometimes the background tasks that propagate permission changes get stuck in the queue.

4

This looks like the classic inheritance chain break. When you have multi-level containers, each level needs to explicitly define whether it inherits from parent or overrides. I’ve found that after major restructuring, you sometimes get orphaned ACL entries that reference deleted or moved containers. The permission cache rebuild helps, but you should also audit your container hierarchy to ensure there are no circular references or broken parent relationships. Use the ACL report utility to export the current state before making changes.

5

Based on your error and the ACL inheritance configuration issues you’re describing, here’s the comprehensive solution:

1. ACL Inheritance Configuration First, verify and fix the inheritance chain. Navigate to each specification container and check the ‘Access Control’ tab. Ensure ‘Inherit access control from parent’ is enabled. If you’ve recently restructured, these flags might have been reset.

2. Container-Level Permissions Audit Run this utility to check effective permissions:


windchill wt.access.AccessControlHelper
  --user <username> --object <container_oid>
  --permission MODIFY

This will show you exactly where the permission chain breaks. Look for containers where the inheritance flag is false or where explicit DENY rules override parent grants.

3. Role-Based Access Control Verification The issue often stems from incomplete role mappings. Go to Site > Utilities > Access Control Administration and verify that:

  • The user’s role is properly assigned at the specification container context
  • The role includes MODIFY rights for EPMDocument types
  • No conflicting role assignments exist at lower levels

4. Permission Cache Rebuild This is critical after any ACL restructuring. Execute:


windchill wt.access.AccessControlServerHelper
  --rebuildCache --container <container_oid>

For system-wide rebuild (use during maintenance window):


windchill wt.access.AccessControlServerHelper
  --rebuildAllCaches

5. Verify Propagation After cache rebuild, check that permissions have propagated:

  • Test check-in with a single user first
  • Monitor MethodServer logs for any remaining AccessDeniedException
  • Verify the timestamp on ACL entries matches your rebuild time

Additional Considerations:

  • If using LDAP/AD sync, ensure group memberships are current
  • Check for any workflow-based permission overrides that might conflict
  • Review any custom access control services that might be intercepting the check-in process

The cache rebuild typically takes 15-30 minutes for large systems. Schedule this during low-usage periods and communicate the maintenance window to users.

6

I experienced something similar in 11.1. The problem was that the EPM document check-in process validates permissions at multiple points - first at the folder level, then at the specification container level, and finally at the CAD document level itself. If any of these checks fail, you get that generic AccessDeniedException. Make sure your users have the necessary permissions not just on the container but also on the EPM document type itself.

7

Are you using custom roles? I had a similar problem where role-based access control wasn’t being evaluated correctly because of a mismatch between the role definition and the actual permission requirements. The MODIFY permission might require additional context rights that aren’t obvious. Try checking the effective permissions for a failing user directly on the specification container using the Access Control utility.