After updating our user-role mappings in the genealogy tracking module, several quality engineers are getting ‘Access Denied’ errors when trying to view batch genealogy records. These are users who previously had full access to traceability data.
The error log shows:
Authorization failed: User lacks permission GENEALOGY_READ
Role cache: STALE - last updated 48h ago
This is blocking compliance traceability audits that are due this week. The users are assigned to the ‘QualityEngineer’ role, which should have GENEALOGY_READ permissions according to our role-permission mapping configuration. I suspect the authorization cache isn’t refreshing properly after the role mapping changes. Has anyone dealt with role-permission mapping issues or authorization cache problems in genealogy tracking?
I’ve seen this exact issue. The problem is usually that role mappings are cached at multiple levels - application cache, session cache, and database connection pool cache. Clearing one doesn’t clear them all. You need to do a full application restart to ensure all caches are cleared. But before that, check your database directly - query the ROLE_PERMISSIONS table to confirm the mapping exists at the database level. Sometimes the UI shows the mapping but it didn’t actually commit to the database.
The ‘STALE - last updated 48h ago’ message is your smoking gun. Honeywell MES caches role-permission mappings for performance, but after role updates, you need to manually invalidate the cache. Try restarting the authorization service, or if you have admin access, there should be a cache management console where you can flush the authorization cache specifically. Look for a ‘Clear Security Cache’ option in the admin portal under System Administration.
Check if your users are still actually assigned to the QualityEngineer role after the mapping update. Sometimes when you modify role mappings, it can inadvertently clear user-role assignments. Go to User Management and verify each affected user’s role assignments. Also, genealogy module does have its own authorization layer - check genealogy-security.xml to ensure the GENEALOGY_READ permission is properly mapped to the module’s access control list.