We upgraded to Aras 14.0 last month and now several non-admin users have lost access to quality management reports they previously could view. The issue affects primarily role-based report permissions where users in the Quality Inspector and Quality Manager roles can no longer access compliance audit reports or CAPA tracking dashboards. What’s strange is that some reports work fine while others throw access denied errors. I’ve verified the user-role assignments haven’t changed and the identity assignments look correct in the database. The reports were working perfectly in 13.0. Has anyone experienced similar permission inconsistencies after upgrading? I’m particularly concerned about inherited permissions from parent quality records not flowing through correctly to the reporting layer. We have an audit next week and need these reports accessible urgently.
I worked through this exact scenario with a client last quarter. The root cause is a combination of factors introduced in Aras 14.0’s enhanced security model. Here’s the comprehensive solution addressing role-based report permissions, user-role assignment sync, and inherited permissions:
Role-Based Report Permissions: First, verify that your report definitions have the correct permission structure. Navigate to Administration > ItemTypes > qry_QueryDefinition and check permissions on your quality reports. Each report needs explicit can_get permissions for Quality Manager and Quality Inspector roles. However, this alone isn’t sufficient - you also need to ensure the report’s owned_by_id isn’t set to a specific user identity, which would override role-based access.
User-Role Assignment Synchronization: The 14.0 upgrade introduced a new permission evaluation cache mechanism. Force a complete permission resync by running the ‘Apply Updates’ utility from Administration > Apply. Select ‘Permission Updates’ and target your Quality-related ItemTypes. This rebuilds the permission cache and resolves most sync issues. Additionally, have affected users perform a hard logout (not just closing the browser) to clear their client-side permission cache.
Inherited Permissions: This is the critical piece most people miss. In 14.0, inherited permissions on reporting objects now follow a stricter evaluation chain. Your quality reports likely query against Quality Issue, CAPA, and related ItemTypes. Check each source ItemType’s permission structure:
- Go to Administration > ItemTypes > Quality Issue (and each related type)
- Verify the Access tab shows your Quality roles with proper can_get access
- Check the ‘Allowed Workflow States’ - if reports query items in specific workflow states, those states need explicit read permissions
- Most importantly, check for any ‘Deny’ permissions on the World identity that might have been added during upgrade migration
For the inherited permission flow to work correctly, create a permission inheritance chain:
- Quality Issue ItemType: Grant can_get to Quality Manager, Quality Inspector
- CAPA ItemType: Grant can_get to Quality Manager, Quality Inspector
- qry_QueryDefinition (your reports): Grant can_get to Quality Manager, Quality Inspector
- Ensure no conflicting deny rules exist at any level
Immediate Fix for Audit: If you need reports working immediately, temporarily grant can_get permission on affected reports to the specific user identities (not ideal long-term, but gets you through the audit). Then systematically work through the proper role-based permission structure.
Run this diagnostic query to identify permission conflicts:
SELECT it.name as ItemType, p.behavior, i.keyed_name as Identity
FROM [innovator].[PERMISSION] p
JOIN [innovator].[ITEMTYPE] it ON p.source_id = it.id
JOIN [innovator].[IDENTITY] i ON p.related_id = i.id
WHERE it.name IN ('Quality Issue', 'CAPA', 'qry_QueryDefinition')
AND p.behavior = 'deny'
Any deny rules returned need investigation. The 14.0 upgrade sometimes adds defensive deny rules that block inherited access patterns that worked in 13.0.
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this before. Check if your report definitions have explicit identity permissions set that might be overriding the role-based access. After 14.0 upgrade, some report ItemTypes got new security contexts that need manual adjustment.
We had similar issues post-upgrade. The problem was that custom quality reports weren’t migrated with the correct permission inheritance flags. Navigate to Administration > Reports > your quality reports and verify the ‘can_get’ permission includes your Quality roles. Also check if the underlying qry_QueryDefinition items have proper access rights. Sometimes the upgrade process doesn’t preserve custom permission structures on reporting objects, especially if they were created through custom methods rather than standard UI.
Thanks for the suggestions. I checked the report definitions and the permissions look correct at that level. The Quality Manager and Quality Inspector roles are both listed with can_get access. However, I noticed that some of the source ItemTypes the reports query against (like Quality Issue and CAPA) might have permission changes. Could that be blocking report access even if the report itself has correct permissions?
Definitely check the source ItemType permissions. Reports inherit security from the data they query. Run this to verify: SELECT id, permission_id, related_id FROM [innovator].[PERMISSION] WHERE source_id IN (SELECT id FROM [innovator].[ITEMTYPE] WHERE name IN (‘Quality Issue’, ‘CAPA’)). Look for any World identity denials that might have been added during upgrade.
I’d also recommend checking the user-role assignment synchronization. In 14.0, there’s a new permission evaluation cache that sometimes gets out of sync after upgrades. Try having affected users log out completely and clear their browser cache, then log back in. This forces a fresh permission evaluation. We’ve seen cases where the server-side cache held stale permission data from pre-upgrade.
Another angle - check if your quality reports use any custom Methods that query data. If those Methods don’t have proper identity context or use IOMethods with elevated permissions, the permission check might fail at the Method execution level rather than the report level. Review any custom code in your report generation workflow.