On-call Scheduling Security Model - Support and Troubleshooting

On-call Scheduling Security Model Description

On-call Scheduling Security Model

Overview 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

Delegate Roles 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.