自动分配工单到团队

名称:自动分配工单到团队

描述:根据可配置的OQL规则自动分派工单。

版本:1.0.8

发布:2019-06-16

itop-version-min:2.4.0

代码:combodo-autodispatch-ticket

状态:稳定

扩散:iTop集线器

进入状态时,自动为团队提供分派工单。

特征

根据预定义分派规则,允许分派自动将工单分配给一个团队,而触发器授予一个转换。

每次工单进入状态时,iTop都会搜索适用于该类和状态的分派规则。如果找到一个,则使用每个团队规则来检索一个团队。工单被分配给找到的第一个团队,并且工单移至其他状态。如果找不到团队,则工单保持不变。

示例:创建工单时,它将自动分派给具有在客户交付模式上定义的角色'支持级别1'的团队,然后移至状况'分派'。

此扩展允许定义:

  • 工单的不同子类的不同规则,
  • 排序查询以检索要使用的团队,
  • 如果设置了团队,则强制使用自动转换(从而触发通知)

可以根据以下条件分配团队:

  • 工单的客户
  • 服务的服务或子服务
  • 提交人的位置
  • 当前时间和适用的覆盖范围窗口
  • 或您可能需要的任何其他逻辑...

以及这些的任何组合。

如果退回了不止一个团队,则将首先使用第一个团队,但不能保证它始终是同一团队。

修订记录

日期版本描述
2019-06-161.0.8*当团队规则不返回任何团队且未调度工单时,请勿在工单的日志中记录成功
*如果不适用刺激措施,请记录错误并继续使用对象的运维
*修复用于匹配的无效目标规则
*修复了在分派规则中创建工作时段时的错误
2019-03-191.0.7修复分派规则不适用于用户和竖井创建的工单
2019-01-171.0.6添加Combodo许可证
2018-12-071.0.4更新翻译
2018-06-261.0.3修正英文翻译
2017-10-271.0.2添加了德语翻译。 (感谢ITOMIG GmbH)
2017-09-261.0.0首个正式版本。

局限性

该扩展是在combodo-approval-light或combodo-approval-extended之后执行的,因此,如果批准规则更改了对象的状态,则不会计算应在先前状态下应用的批准规则。

分派规则必须在每个最终类上定义,而不是抽象类上定义。此扩展名并非旨在在不更改状态的情况下组建团队。

要求

Top 2.4或更高版本

  • 扩展基于工作时段的SLA v2.1或更高版本

安装

使用标准安装流程 对于此扩展。

配置

在iTop配置文件中没有定义参数。

用法

分派规则

为一类工单定义了分派规则。它必须至少包含一个团队规则和一个状态规则。

首先通过打开服务管理下的相应菜单来创建新的分派规则。

https://www.itophub.io/wiki/media?w=600&tok=f73901&media=extensions%3Acombodo-autodispatch-ticket-01.png

名称强制性的描述
名称强制性的描述分派规则的名称
强制性的工单规则将适用于的类
属性团队强制性的工单类的属性代码将由匹配的Team规则设置
解释日志属性可选的工单类的属性代码,将使用解释团队规则如何匹配的文本进行设置
禁用的上下文可选的上下文标签的CSV列表,其中分派规则将处于非活动状态。通常是门户(“ GUI:门户”),cron选项卡(“ CRON”),rest/json调用(“ REST/JSON”),…

从iTop 2.4开始,可以使用以下上下文(可以从扩展添加更多上下文):

  • 面:控制台:管理控制台
  • GUI:门户:任意门户
  • 户:<PORTAL_ID>:一个特定的门户实例
  • 步:任何同步数据源
  • 同步:<DATASOURCE_RAWNAME>:特定的同步数据源
  • CRON:任何CRON任务
  • CRON:任务:<TASK_CLASSNAME>:特定的CRON任务
  • RESTTJSON:RESTTJSON调用

国家规定

状态规则定义要自动对团队进行分派的状态,以及在找到团队时必须应用的转换。

在“状态”选项卡中至少创建一个状态规则。

https://www.itophub.io/wiki/media?w=600&tok=ae4bac&media=extensions%3Aautodispatch-newstaterule.png

名称强制性的描述
状态代码强制性的工单状态的代码。进入此状态将触发器分派规则
刺激码强制性的如果找到团队,将应用激励代码

团队规则

团队规则定义了如何将团队检索到分派。

在相应的标签中至少创建一个团队规则。

https://www.itophub.io/wiki/media?w=600&tok=ac0756&media=extensions%3Aautodispatch-newteamrule.png

名称强制性的描述
名称强制性的规则的免费名称,适用于人类。
Q强制性的查询必须返回团队对象
工作时段可选的仅当我们在工作时段内时才使用团队规则
强制性的使用小组规则的顺序,从最低的数字开始。
活性强制性的允许准备团队规则,而不激活它们。带有“否”的规则将不被使用。

使用范例

规则至分派一个团队

请记住,工单。team_id上有一个过滤器:

SELECT Team AS t 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=t.id 
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id=dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
WHERE o.id = :this->org_id

在工单上自动分配的团队应符合工单。team_id上定义的过滤器。

您可能需要变更或过滤器,或将所有适用的团队置于交付模式下

默认团队

在auto-分派的beta版本中,iTop使用此逻辑分配了一个团队

SELECT Team AS t 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=t.id 
  JOIN ContactType AS ct ON l1.role_id=ct.id
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id = dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
WHERE o.id=:this->org_id AND ct.name='Support level1'

根据服务分配团队

您可能希望为每个服务定义一个支持团队,在这种情况下,最好的做法是在服务上添加一个新的属性support_team_id,作为团队的外部密钥。

但是,您也可以保留默认数据模型,并确保只有一个团队链接到每个服务。

如果有一个,您可能想使用服务上定义的团队,否则,请使用客户的交付模式上定义的默认团队。在这种情况下,您将创建2个团队规则,一个基于最低级别的服务,另一个使用上述OQL。

禁用的上下文

当用户通过控制台中的同步,脚本或处理人员创建工单时,要通过门户创建用户的自动分派工单,从发送邮件创建工单的工单是很常见的。这就是“禁用上下文”字段的目的。

甚至可以仅针对一个特定的门户或特定的DataSynchro禁用分派规则。使用的语法是:

  • 门户:<portal-id>其中<portal-id>是XML中定义的门户ID
  • 同步:<synchro-name>其中<synchro-namee>是该特定数据同步器的名称

示例:假设您已经为代理创建了特殊的门户,并且希望通过该门户创建的工单不被自动发送。

  <portals>
    <portal id="agent-portal" _delta="define">
    ...

然后,要禁用分派规则,请设置“禁用上下文” =Portal:agent-portal.

原贴链接:https://www.itophub.io/wiki/page?id=extensions%3Acombodo-autodispatch-ticket


Auto dispatch ticket to a team

name:
Auto dispatch ticket to a team
description:
Automatically dispatch tickets based on the configurable OQL rules.
version:
1.0.8
release:
2019-06-16
itop-version-min:
2.4.0
code:
combodo-autodispatch-ticket
state:
stable
diffusion:
iTop Hub

Automatically dispatch tickets to teams when entering a state.

Features

Allow to dispatch automatically Ticket based on predefined Dispatch rules, to a team and trigger a transition.

Each time a Ticket enter a state, iTop searched for Dispatch rules which apply to this class and state. If it finds one, then it uses each Team rules in order to retrieve a team. The Ticket is assigned to the first team found and Ticket is moved to a different state. If no team is found, the Ticket is left unchanged.

Example: when a Ticket is created, it is automatically dispatched to the team with role 'Support level1' defined on the customer Delivery Model, and moved to status 'Dispatch'.

This extension allows to define:

  • different rules for different sub-class of Ticket,

  • ordered queries to retrieve the team to use,

  • force an automatic transition, if a team was set (thus triggering notification)

Team can be assigned based on:

  • customer of the ticket

  • service or sub-service of the ticket

  • location of the caller

  • current time and applicable coverage windows

  • or any other logic you may need…

And any combination of those.

If more than one team is returned, first will be used without guarantee that it will always be the same one.

Revision History

DateVersionDescription
2019-06-161.0.8* When team rules return no team and ticket is not dispatched, don't log success in ticket's log
* When a stimulus is not applicable, log the error and pursue the object's operation
* Fix inactive target rules being used for matching
* Fix a bug when creating coverage window within a dispatch rule
2019-03-191.0.7Fix dispatch rule not working for Tickets created by a user with silos
2019-01-171.0.6Add Combodo license
2018-12-071.0.4Update translations
2018-06-261.0.3Fix english translation
2017-10-271.0.2Added German translation. (thanks to ITOMIG GmbH)
2017-09-261.0.0First official version.

Limitations

This extension is executed after combodo-approval-light or combodo-approval-extended, therefore if an Approval rule changes the object's state, Dispatch rules that should have been applied on the previous state will not be computed.

Dispatch rules must be defined on each final class, not on abstract class. This extension is not designed to set a team without changing the state.

Requirements

  • iTop 2.4 or later

  • Extension SLA considering business hours v2.1 or more

Installation

Use the Standard installation process for this extension.

Configuration

There is no parameter defined in the iTop configuration file.

Usage

Dispatch Rule

A dispatch rule is defined for one Class of Ticket. It must contain at least one Team rule and one State rule.

First create a new Dispatch rule by opening the corresponding menu under Service Management.

https://www.itophub.io/wiki/media?w=600&tok=f73901&media=extensions%3Acombodo-autodispatch-ticket-01.png

NameMandatoryDescription
NameMandatoryA name describing the dispatch rule
ClassMandatoryTicket class the rule will apply to
Team attributeMandatoryAttribute code of the Ticket Class that will be set by the matching Team rule
Explain log attributeOptionalAttribute code of the Ticket Class that will be set with a text explaining how a Team rule matched
Disabled contextsOptionalA CSV list of context tags in which the Dispatch rule will be inactive. Typically a portal (“GUI:Portal”), cron tab (“CRON”), a rest/json call (“REST/JSON”), …

As of iTop 2.4, the following contexts are available (more can be added from extensions) :

  • GUI:Console: The administration console

  • GUI:Portal: Any portal

  • Portal:<PORTAL_ID>: A specific portal instance

  • Synchro: Any synchro datasource

  • Synchro:<DATASOURCE_RAWNAME>: A specific synchro datasource

  • CRON: Any CRON task

  • CRON:Task:<TASK_CLASSNAME>: A specific CRON task

  • REST/JSON: A REST/JSON call

State Rule

A State rule defines the state in which you want to auto-assign a team, and which transition must be applied if a team was found.

Create at least one State rule in the States tab.

https://www.itophub.io/wiki/media?w=600&tok=ae4bac&media=extensions%3Aautodispatch-newstaterule.png

NameMandatoryDescription
State codeMandatoryCode of the Ticket state. Entering this state will trigger the Dispatch rule
Stimulus codeMandatoryCode of the Stimulus that will be applied if a team is found

Team Rule

A Team rule defines how to retrieve the team to assign.

Create at least one Team rule in the corresponding tab.

https://www.itophub.io/wiki/media?w=600&tok=ac0756&media=extensions%3Aautodispatch-newteamrule.png

NameMandatoryDescription
NameMandatoryFree name of the rule, for humans.
OQLMandatoryQuery which must return Team objects
Coverage windowOptionalThe Team rule will be used only if we are within the Coverage window
RankMandatoryOrder for using the Team rules, lowest number first.
ActiveMandatoryAllow to prepare Team rules, without activating them. Rules with 'No' will not be used.

Examples of usage

Criteria to assign a team

Remember that, there is a filter on Ticket.team_id:

SELECT Team AS t 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=t.id 
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id=dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
WHERE o.id = :this->org_id

Teams auto-assigned on a Ticket should be compliant with the filter defined on Ticket.team_id

You may have to change that filter or to put all applicable teams under the Delivery Model

Default Team

In beta version of auto-dispatch, iTop assigned a team using this logic

SELECT Team AS t 
  JOIN lnkDeliveryModelToContact AS l1 ON l1.contact_id=t.id 
  JOIN ContactType AS ct ON l1.role_id=ct.id
  JOIN DeliveryModel AS dm ON l1.deliverymodel_id = dm.id 
  JOIN Organization AS o ON o.deliverymodel_id=dm.id 
WHERE o.id=:this->org_id AND ct.name='Support level1'

Assigning a team based on Service

You may want to define a support team per Service, in which case, the best is to add a new attribute support_team_id on Service, as an ExternalKey to a Team.

But you may also keep the default datamodel and ensure that only one single team is linked to each service.

You may want to use the team defined on the Service when there is one, otherwise use the default team defined on the delivery model of the customer. In which case you will create 2 Team rules, one based on Service with the lowest rank and the other using the OQL above.

Disabled contexts

It is quite common that you want to Auto-Dispatch tickets created by users through the Portal, Ticket creation from Email, but do not want to do it, when the ticket is created by a synchro, a script or maybe an agent in the console. That's the purpose of the Disabled contexts field.

It is even possible to disable a Dispatch rule just for one particular Portal or a particular DataSynchro. The syntax to use is:

  • Portal:<portal-id> where <portal-id> is the portal id defined in the XML

  • Synchro:<synchro-name> where <synchro-name> is the name of that particular Datasynchro

Examples: Let's say you have created a special portal for your agents and you want Tickets created through that portal not to be auto-dispatched.

  <portals>
    <portal id="agent-portal" _delta="define">
    ...

Then to disable the Dispatch rule, set Disabled contexts = Portal:agent-portal.

标签:
由 superadmin 在 2020/08/25, 16:40 创建
    

需要帮助?

如果您需要有关XWiki的帮助,可以联系:

深圳市艾拓先锋企业管理咨询有限公司