/
User Permissions for Playback

User Permissions for Playback

Jun 10, 2019


MoSCoW Rating for Deimos Release:

Must

Business Case

Allows businesses to manage their rules and users in a central location this reduces the administration overhead for administrators of both systems.

Personas effected

Personas can be found in Azure DevOps: https://redboxdev.visualstudio.com/Nubis/_apps/hub/agile-extensions.personas.hub 

Please be aware that 

The following personas will be interested in ensuring that there is a centre place for managing user permissions in order to reduce administration, ensure everyone has the correct levels of access and reduce user management costs. They are also interested in the value this feature has against risk management as well as time overhead - if everything is managed via AD, you can't forget to disable a user in core services and have a security breach for example.

  • Toby Lerone - Head of IT Service Management 
  • Gary Baldi - Customer Experience/ Contact Centre Manager 
  • Penn Gwynn - Head of Contact Centre 

Functionality

For the context of this functionality there is a clear differentiation between the term 'User' and 'Agent':

  • User is defined as an an individual who can log on the EA to view calls that have been made and listen to them. This will be set up within the customers AD.
  • Agent is defined as the individual who makes and receives calls which are recorded and stored for viewing on the EA. This will be set up within the EA.


This feature is focused only on permissions for historical replay of calls, Record On Demand is outside of the scope of this feature. Within the scope of this feature we will be looking to deliver two core pieces of functionality:

Mapping the Agent ID to AD GUID 

We need to allow the admin to use Core Services to map the Agent ID to the AD GUID. Within the scope of MVP we will be keeping user and agent as separate entities, we will also only be targeting functionality related to Auto Discovery. Role Mapping has already been completed by Team Charlie.

Understanding what the rule is setup within AD so that we can pull that permission level into the EA

Once we have the ability to map Agent ID to AD GUID we will need to be able to see what AD Group the Agent has been placed in so that we can read the permission level they have assigned and implement that permission within the EA. When an agent is associated with a permission which allows them to view calls they are also able to access the Metadata for that call.

Configuration for MVP - Auto Discovery

Please note: Steps 1 - 4 already exist as part of Agent to Device Mapping 

  1. When a collector discovers a new device, Core Services automatically detects it
  2. Admin will then need to manually add the agent related to that device to Core Services
  3. The admin sets up Agent with the following fields:
    1. First name
    2. Last name
    3. Email (optional)
    4. Department (optional)
  4. The admin then maps the Agent ID to Device ID(s)
    Note: Agent IDs can be linked to multiple device IDs
  5. Admin then goes into their companies AD and sets up a User
  6. They will then place this User in an AD Group: 
    1. User can view and listen to only their own calls
    2. User can view and listen to all calls on the system
  7. By default if a User is not placed within a AD Group they will not be able to view or listen to any calls on the EA
  8. The admin will then manually map the user within AD to the Agent within EA using the Agent ID and the AD GUID within Core Services


Post MVP - Future Functionality 


In the future we will be looking to make Agents and Users the same thing by syncing the Users already set up within AD to Core Services. A further extension of this functionality will be to have a 1-2-1 mapping between Users and Agents, this functionality will be covered by future sets of functional requirements.



Sign Off

Add label