User permissions not applying correctly after role changes in resource-management

ERP Infor CloudSuite
, , , , , , , ,
1

We recently promoted several team members to project lead roles and updated their security roles accordingly in Resource Management. However, they’re unable to access the resource allocation screens they need. I’ve verified the role assignments multiple times - the users show the correct “Project Lead” role in their profile, but when they try to access Resource Allocation or Capacity Planning screens, they get “Access Denied” errors.

Here’s what I’ve checked:


User: jsmith
Assigned Role: PROJECT_LEAD
Role Permissions: RESOURCE_ALLOCATE, CAPACITY_VIEW
Access Test: FAILED - Error 403

I’ve run the security role synchronization job, cleared user caches, and even had users log out and back in. The role assignments look correct in the admin console, but the actual permissions aren’t taking effect. This is blocking critical resource planning activities. Has anyone encountered permission propagation issues after role changes in ICS 2023.1?

2

I’ve seen this in 2023.1 specifically. There’s a known issue where role changes don’t immediately update the permission cache for active user sessions. The security sync job you ran only updates the database, but the application cache needs separate clearing. Try running the Clear Application Cache job from System Administration > Cache Management, then have users clear their browser cache and restart their sessions. Also verify that the PROJECT_LEAD role definition includes the Resource Management module in its scope.

3

First thing to check - are these users also assigned to any other roles that might have conflicting permissions? CloudSuite uses a deny-wins model, so if any assigned role has an explicit deny for those screens, it overrides the allow permissions from other roles. Check their complete role list, including inherited organizational roles.

4

I checked for conflicting roles and found that two of the affected users still have their old “Team Member” role assigned alongside the new “Project Lead” role. Could that be causing the issue even if Team Member doesn’t have explicit deny permissions? Also, when I look at the PROJECT_LEAD role definition, I see it has module access for Resource Management, but I’m not sure if the specific screen permissions are properly configured.

5

Your issue involves three interconnected problems that need systematic resolution:

Role Assignment Cleanup: The multiple role assignments are creating permission conflicts. Here’s how to clean this up properly:

  1. Remove old role assignments:

    • Navigate to User Management > User Roles
    • For each affected user, remove the “Team Member” role
    • Keep only the “Project Lead” role assigned
    • Important: Do this before any other fixes, as multiple roles create unpredictable permission states

  2. Verify role hierarchy:

    • Check if users inherit any roles from organizational unit membership
    • System Administration > Security > Role Hierarchy
    • Document all inherited roles - these contribute to final permissions

Resource Allocation Screen Access: Role permissions and screen access are configured separately. You need to verify both:

  1. Role permission verification:

    • Go to System Administration > Security > Roles
    • Edit the PROJECT_LEAD role
    • Navigate to the Permissions tab
    • Verify these specific permissions are checked:
      • RESOURCE_ALLOCATE (allows allocation changes)
      • CAPACITY_VIEW (allows viewing capacity data)
      • RESOURCE_PLAN_EDIT (allows editing resource plans)

  2. Screen-level access configuration:

    • Still in the PROJECT_LEAD role editor, go to Screen Access tab
    • Add explicit entries for:
      • Screen ID: RM_RESOURCE_ALLOCATION
      • Screen ID: RM_CAPACITY_PLANNING
    • Set access level to “Full Access” for both

  3. Module scope verification:

    • In the role definition, check Module Scope section
    • Ensure “Resource Management” is listed with scope=“FULL”
    • If scope is “LIMITED”, expand it or specify which sub-modules are included

Permission Propagation and Cache: Role changes require multiple cache clearing operations:

  1. Clear security cache:

    
System Administration > Jobs > Run Job
Job: Security.clearRoleCache
Scope: ALL_USERS

  2. Clear application cache:

    • System Administration > Cache Management > Clear Application Cache
    • Select “Security” and “User Session” cache types
    • Click Clear Now

  3. Force session refresh:

    • Have affected users completely log out (not just close browser)
    • Wait 5 minutes for session cleanup
    • Clear browser cache and cookies
    • Log back in with fresh session

  4. Verify organizational access:

    • Resource Management > Configuration > Organizational Access
    • Check access matrix for Resource Allocation and Capacity Planning screens
    • Ensure the organizational units your project leads belong to have appropriate access levels
    • If they were promoted from lower org units, their org unit assignment might need updating

Additional Troubleshooting: If access still fails after the above:

  1. Check for data-level security:

    • Some organizations implement row-level security that restricts which resources users can see
    • Verify project leads have data access to the resources they’re trying to allocate
    • Resource Management > Security > Data Access Rules

  2. Review audit logs:

    • System Administration > Audit > Security Audit Log
    • Filter for the affected users and “Access Denied” events
    • The log details will show exactly which permission check is failing

  3. Test with a clean test user:

    • Create a new test user
    • Assign only the PROJECT_LEAD role
    • Assign to same organizational unit as affected users
    • Test access - if this works, the issue is user-specific configuration

ICS 2023.1 Specific Considerations: This version has a known caching issue with role changes. After completing the above steps, if problems persist:

  • Apply the latest update rollup for ICS 2023.1 (check for security-related patches)
  • Consider scheduling a brief application restart during off-hours to ensure complete cache refresh
  • Document this process for future role changes to avoid recurrence

The combination of removing conflicting role assignments, verifying screen-level permissions, and properly clearing all cache layers should resolve your access issues. The key is addressing all three areas systematically rather than focusing on just role assignments.

6

Yes, multiple role assignments can definitely cause problems. Even without explicit denies, having both Team Member and Project Lead roles can create ambiguous permission states. Best practice is to remove the old role when assigning the new one. Also, screen-level permissions are separate from module access - having Resource Management module access doesn’t automatically grant access to all screens within it. You need to verify that the Resource Allocation and Capacity Planning screens are specifically listed in the PROJECT_LEAD role’s screen permissions.

7

Check the Resource Management configuration for organizational unit restrictions. Sometimes roles grant permissions but the screens themselves are restricted by organizational hierarchy. If your project leads were promoted from a lower-level org unit, they might have the role permissions but not the org unit access level required for those screens. Navigate to Resource Management > Configuration > Organizational Access and verify the access levels for the screens in question.