Roles¶
The Role visual editor is a supervisor (or admin) tool that you can use to view a list of system roles and assign permissions to them for individual users, groups, and so on.
The editor can be found in FrontStage administration, section . You need the EditRole role.
The running editor displays a list of all the existing roles. It is also filled with a result of the data query. Its ID is in the RoleAdminQueryId configuration parameter.
For a detailed list of roles, see this article
In the upper right corner there are buttons for interacting with the records:
Create permission to roles - Bulk operation. Creates a permission level for the selected records, which you enter in the window triggered by this button.
Warning
Roles cannot be created or deleted by a regular user. Buttons for these actions are missing.
How do the roles and permissions work?¶
“Role” is the name for a group of actions you can enable or disable by assigning permissions.
To apply to a specific user, you must create a Permission, which refers to a role in the selected degree that controls a specific restrictions or permissions. The Permission degree takes six values, named DenyRead, DenyWrite, DenyFull, AllowRead, AllowWrite, and AllowFull. Most roles don’t use all degrees. You can always find a description of all valid ones for a given role.
When setting permissions, it is important to remember that the user will always have the highest permissions of all those that apply to them. For example, if he is a member of a team that has the EditCampaign role at the AllowRead degree, but he has EditCampaign = AllowFull, then AllowFull will be used.
Detail tab¶
ID - GUID, not editable.
System name - Unique name of the role. Used in documentation and standard text to reference the role.
Display name - The general name of the role.
Group - Role categorization.
Description - Should describe the role in detail, but the description is not always clear in the database. For a detailed description look for the role here in the documentation
Permissions tab¶
Represents a list of all permissions assigned to the role. You can add/remove, or edit existing permissions from the list here.
Permission editor consists of:
ID - GUID, not editable.
Scope - Restricts the set permission to only certain items related to it. Each role supports a different scope; some do not work with it at all. If a role supports one, this will be mentioned in the description. For an example of a detailed scope, see the Activities tab bulk actions article.
Permission degree - Select one of six levels. Each level is represented differently for each role. Their meaning is described for each role.
Language - Permission valid only if the agent is working on a communication in this language. Only applicable to specific roles.
Agent - Selection of the agent to which the authorization applies.
Queue group mask - Queues can be grouped. If you specify the name of a queue group here, the permission will be valid only for work related to the queue belonging to the group.
Administrator - Permissions are valid only if the agent has the “administrator” flag. Configurable via the Agents visual editor.
Queue - Permissions are valid only if the agent is working on the communication assigned to this queue. Only applicable to specific roles.
Supervisor - Permissions are valid only if the agent has the “supervisor” flag. Configurable via the Agents visual editor.
Team Mask - Agents can be divided into teams. If you specify the name of an existing team here, permission will be given to that team.
Min. skill - The lower limit of agent skills at which the permission can be valid. Only applicable to specific roles.
Max Skill - The upper limit of agent skills at which the permission can be valid. Only applicable to specific roles.
Note
The mask writing style supports the principle of the LIKE operator from SQL. For a full list of notation options, see the w3schools .
Note
Most of the information on this tab functions similarly to a filter, meaning it refines the destination for permissions. If you want to set some roles across the board for everyone, set only the appropriate permissions level and do not fill in any other information. Permissions established in this way will apply to all users on the system:
