On-call Scheduling Security Model
Have you ever tried delegating the rota_manager for the same user from multiple groups? sys_user_has_role only has 1 entry for the first group.
This works as designed.
Those designated with the rota_manager role can edit Rotas and the associated rosters for the Rota in situations where they are the manager of the Rota group.
The rota_admin role needs granted to update Rotas without being a manager of the group.
Here is how the security model for Rotas works:
- ADMIN - Access to everything in the system including Rota
- rota_admin - Basic CRUD operation for Rota records
- rota_manager + group manager/ delegate - Ability to CRUD only to that groups' records
To delegate roles, the manager in this case, must be a role_delegator. This is completed by visiting the following module in the navigator:
User Administration > Role Delegation > Delegate Roles In Group
To delegate roles as a role_delegator, visit the following module in the navigator:
User Administration > Role Delegation > Designate Role Delegation
The manager can then give a member the rota_manager role, and this generates a sys_user_has_role record specifying the role has been granted by the group.
This user is now able to maintain the rotations for that group only, because it has been granted by that group only.
To modify the above behavior, investigate the OnCallSecurityNG script include, specifically the rotaMgrAccess function as this determines whether a groups Rotas should be editable in the calendar.
The helper function uses the platform (gs.hasRoleInGroup) to check whether the user has been granted the role by the current group.