本帖最后由 adminlily 于 2020-12-8 11:01 编辑
自动分配工单到团队名称:自动分配工单到团队
描述:根据可配置的OQL规则自动分派工单。 版本:1.0.8 发布:2019-06-16 itop-version-min:2.4.0 代码:combodo-autodispatch-ticket 状态:稳定 扩散:iTop集线器
进入状态时,自动为团队提供分派工单。
特征
根据预定义分派规则,允许分派自动将工单分配给一个团队,而触发器授予一个转换。
每次工单进入状态时,iTop都会搜索适用于该类和状态的分派规则。如果找到一个,则使用每个团队规则来检索一个团队。工单被分配给找到的第一个团队,并且工单移至其他状态。如果找不到团队,则工单保持不变。
示例:创建工单时,它将自动分派给具有在客户交付模式上定义的角色'支持级别1'的团队,然后移至状况'分派'。
此扩展允许定义:
- 工单的不同子类的不同规则,
- 排序查询以检索要使用的团队,
- 如果设置了团队,则强制使用自动转换(从而触发通知)
可以根据以下条件分配团队:
- 工单的客户
- 服务的服务或子服务
- 提交人的位置
- 当前时间和适用的覆盖范围窗口
- 或您可能需要的任何其他逻辑...
以及这些的任何组合。
如果退回了不止一个团队,则将首先使用第一个团队,但不能保证它始终是同一团队。
修订记录
日期 | 版本 | 描述 | 2019-06-16 | 1.0.8 | *当团队规则不返回任何团队且未调度工单时,请勿在工单的日志中记录成功
*如果不适用刺激措施,请记录错误并继续使用对象的运维
*修复用于匹配的无效目标规则
*修复了在分派规则中创建工作时段时的错误 | 2019-03-19 | 1.0.7 | 修复分派规则不适用于用户和竖井创建的工单 | 2019-01-17 | 1.0.6 | 添加Combodo许可证 | 2018-12-07 | 1.0.4 | 更新翻译 | 2018-06-26 | 1.0.3 | 修正英文翻译 | 2017-10-27 | 1.0.2 | 添加了德语翻译。 (感谢ITOMIG GmbH) | 2017-09-26 | 1.0.0 | 首个正式版本。 |
局限性
该扩展是在combodo-approval-light或combodo-approval-extended之后执行的,因此,如果批准规则更改了对象的状态,则不会计算应在先前状态下应用的批准规则。
分派规则必须在每个最终类上定义,而不是抽象类上定义。此扩展名并非旨在在不更改状态的情况下组建团队。
要求
Top 2.4或更高版本
安装
配置
在iTop配置文件中没有定义参数。
用法
分派规则
为一类工单定义了分派规则。它必须至少包含一个团队规则和一个状态规则。
首先通过打开服务管理下的相应菜单来创建新的分派规则。
名称 | 强制性的 | 描述 | 名称 | 强制性的 | 描述分派规则的名称 | 类 | 强制性的 | 工单规则将适用于的类 | 属性团队 | 强制性的 | 工单类的属性代码将由匹配的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调用
国家规定
状态规则定义要自动对团队进行分派的状态,以及在找到团队时必须应用的转换。 在“状态”选项卡中至少创建一个状态规则。
名称 | 强制性的 | 描述 | 状态代码 | 强制性的 | 工单状态的代码。进入此状态将触发器分派规则 | 刺激码 | 强制性的 | 如果找到团队,将应用激励代码 |
团队规则
团队规则定义了如何将团队检索到分派。
在相应的标签中至少创建一个团队规则。
名称 | 强制性的 | 描述 | 名称 | 强制性的 | 规则的免费名称,适用于人类。 | Q | 强制性的 | 查询必须返回团队对象 | 工作时段 | 可选的 | 仅当我们在工作时段内时才使用团队规则 | 秩 | 强制性的 | 使用小组规则的顺序,从最低的数字开始。 | 活性 | 强制性的 | 允许准备团队规则,而不激活它们。带有“否”的规则将不被使用。 |
使用范例
规则至分派一个团队
请记住,工单。team_id上有一个过滤器:
在工单上自动分配的团队应符合工单。team_id上定义的过滤器。
您可能需要变更或过滤器,或将所有适用的团队置于交付模式下
默认团队
在auto-分派的beta版本中,iTop使用此逻辑分配了一个团队
根据服务分配团队
您可能希望为每个服务定义一个支持团队,在这种情况下,最好的做法是在服务上添加一个新的属性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.
|