Users in our shared manufacturing workspaces are getting ‘Access Denied’ errors when trying to run collaboration reports from Analytics Dashboard. The error message shows:
wt.access.AccessControlException: Access denied
at wt.access.AccessControlServerHelper.check()
at wt.query.QueryHelper.executeQuery()
The same users can view the manufacturing data in the workspace UI without issues. They have ‘Contributor’ role in the workspace and can edit manufacturing parts and process plans. The reports work fine for users with ‘Administrator’ role.
We have about 30 manufacturing engineers who need these reports for daily production planning. This started happening after we upgraded from 11.0 to 11.1 M030. The collaboration workflow depends on these analytics reports.
I’ll provide a comprehensive solution covering all three security aspects of this issue.
Report Object ACLs:
First, let’s address the report definition permissions. Analytics Dashboard reports have two permission layers:
Report definition ACL - controls who can run/edit the report
Query execution context - controls what data the report can access
To fix the report definition ACL:
Navigate to Analytics Dashboard > Manage Reports
Select your manufacturing collaboration reports
Click ‘Properties’ > ‘Access Control’
Verify that ‘Manufacturing’ role has ‘Read’ and ‘Execute’ permissions
If using report folders, check folder ACLs as well - permissions may be inherited
Critical: After the 11.1 upgrade, report ACLs may have reset to default (Administrator-only). You need to explicitly grant Execute permission to the Manufacturing role on each report.
Inherited Permissions:
The core issue is permission inheritance across multiple contexts. Manufacturing collaboration reports typically query:
Workspace objects (manufacturing parts, process plans)
Project objects (if using project-based collaboration)
Windchill 11.1 M030 changed how query permissions are evaluated. Previously, queries would silently filter inaccessible objects. Now they fail fast with AccessControlException if any object in the result set is inaccessible.
Solution approach:
Identify all contexts your reports access:
Review the report query definitions to list all object types and containers being accessed. For manufacturing collaboration, this typically includes:
Create role-based ACL templates:
Define ACL templates for each context that grant appropriate read permissions:
Template: Manufacturing_Library_Read
Manufacturing role: Read, Download
Apply to: Product Library folders containing parts and changes
Template: Manufacturing_Supplier_Read
Manufacturing role: Read
Apply to: Supplier folders accessed by reports
Apply templates systematically:
Use Policy Administrator to apply templates to container hierarchies
Test with one user before broad deployment
Document which templates apply to which contexts
User Context Validation:
The AccessControlException at QueryHelper.executeQuery indicates the query is executing under the user’s context but encountering objects outside their permission scope.
Query context propagation:
When a user runs a report, the query executes under their security context. The query must validate access for EVERY object it touches, not just the final results.
Cross-context query handling:
For reports that span workspaces and libraries, implement these fixes:
Option A - Grant cross-context read permissions:
Give Manufacturing role Read access to all library folders referenced by reports
Use ACL templates for consistent application
This is the recommended approach for collaboration scenarios
Option B - Use a service account for report execution:
Create a dedicated service account with broad read access
Configure Analytics Dashboard to execute specific reports under this account
Edit report properties > Execution > Run As: [service-account]
Less secure but useful for complex cross-context reports
Upgrade-specific considerations:
The 11.0 to 11.1 upgrade modified access control validation in query execution. Review the upgrade guide section on ACL changes. You may need to:
Rebuild ACL caches: Run ‘Rebuild Access Control Cache’ from Site > Utilities
Update custom ACL rules if you have any
Verify domain-based access control settings didn’t change
Implementation steps for your 30 manufacturing engineers:
Immediate fix (Day 1):
Grant Manufacturing role Read access to Product Library > Changes folder
Grant Manufacturing role Read access to Product Library > Parts folder
Grant Manufacturing role Read access to Suppliers folder
Rebuild ACL cache
Test with 2-3 users
Proper solution (Week 1):
Create ACL templates for each context
Document which reports access which contexts
Apply templates systematically
Create test cases for each report
Roll out to all 30 users
Long-term maintenance:
Include ACL requirements in report documentation
When creating new reports, document required permissions
Add ACL validation to your report deployment checklist
Consider using report folders with inherited ACLs for easier management
This three-layer approach (report ACLs, inherited permissions, context validation) will resolve your access denied errors while maintaining appropriate security boundaries for manufacturing collaboration.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
This is a classic ACL inheritance problem. Analytics Dashboard runs reports under a different security context than the interactive UI. The report objects themselves have ACLs that may not match the workspace permissions. Check the ACL on the report definition - it probably grants access only to Administrators, not Contributors.
I checked the report ACLs and they show ‘Full Access’ for the Manufacturing role, which our users have. The error specifically mentions QueryHelper.executeQuery, so maybe it’s failing when the query tries to access the underlying manufacturing objects?
The QueryHelper error indicates the query is accessing objects the user doesn’t have permission to read. Manufacturing collaboration reports often pull data from multiple contexts - workspace objects, library objects, and related change objects. If the report query spans multiple contexts and the user only has permissions in the workspace context, the query will fail on objects outside their scope. You need to verify permissions across all contexts the report touches.
“Confirmed this resolves the issue — granting ‘Read’ and ‘Execute’ permissions to the Manufacturing role in Analytics Dashboard report ACLs eliminated our access denied errors immediately.”
After the 11.1 upgrade, there were changes to how report queries validate permissions. The query now checks read access on every object in the result set before returning data. Previously it would filter out inaccessible objects. Now it throws AccessControlException if ANY object in the query result is inaccessible. Check if your manufacturing reports are trying to access change requests or supplier parts that exist outside the workspace context.
That makes sense. Our collaboration reports do pull in ECO data and supplier information. Those objects are in the product library, not the workspace. How do I grant the manufacturing engineers access to those library objects without making them administrators?
You can use ACL templates to grant read access on library objects to specific roles. Create an ACL template that grants ‘Read’ permission to the Manufacturing role for the relevant library folders (ECOs, supplier parts). Apply this template to the library containers. This gives them read access for reports without full administrative privileges. Make sure to test with a single user before rolling out to all 30 engineers.