让我们看一个例子,更易于阐述流程管理。我们将定义一个订书流程:
在生成订单之前,雇员对书籍的需求将被记录。下列书籍是我们示例中所需要的:
标题: Prozessmanagement für Dummies 作者: Thilo Knuppertz ISBN: 3527703713
假设在这个工作流中,工单可以像随同文档一样接收变更记录,那么我们就有了很清晰的工单处理流程图。
通过示例流程分析,我们可以确定下列需要的条目:
数据记录功能,我们称其为Activity Dialogs 活动对话框,
根据数据变化自动反应的检查,我们称之为Transitions 转换,
在流程单成功转换后,对流程工单的变更,我们称之为 Transition Actions 转换操作。
我们同样还需要一些不那么复杂的额外项:
可能存在不止一个活动对话框(Activity Dialog)。在示例中,经理必须在"Approve 同意" 与 "Deny 拒绝"中做出决定。我们称之为Activity 活动。
现在,结合活动(Activities)、活动对话框(Activity Dialogs)、转换(Transitions)与转换操作(Transition Actions),我们可以对示例的各个独立步骤进行建模。现在还缺少为每个工作流步骤设置具体顺序。我们称之为Process 流程。为了能在之后指代所有这些实体,我们将分配给他们括号中的缩写。这个缩写基于内部识别机制EntityID。
EntityID以1~2个字母开头(取决于流程组件或实体),接着跟随连续编号,例如:
流程: 'P1', 'P2' ... 'Pn'.
活动: 'A1', 'A2' ... 'An'.
活动对话框: 'AD1', 'AD2' ... 'ADn'.
Transition: 'T1', 'T2' ... 'Tn'.
转换操作: 'TA1', 'TA2' ... 'TAn'.
在新建流程和相关内容之前,需要提前准备好系统,我们需要定义一些队列、客户联系人和动态字段,还需要在系统配置中设置一些参数。
创建如下队列:
管理
员工
采购
邮局
创建如下用户:
经理
员工
创建如下动态字段:
标题
标签 | 标题 |
类型 | 文本 |
对象 | 工单 |
作者
标签 | 作者 |
类型 | 文本 |
对象 | 工单 |
ISBN
标签 | ISBN |
类型 | 文本 |
对象 | 工单 |
状态
标签 | 状态 |
类型 | 下拉选项框 |
对象 | 工单 |
可能的值 |
|
注意:需要在创建动态字段的“键”和“值”时尽可能使用最接近的值。
供应商
标签 | 供应商 |
类型 | 文本 |
对象 | 工单 |
价格
标签 | 价格 |
类型 | 文本 |
对象 | 工单 |
交货日期
标签 | 交货日期 |
类型 | 日期 |
对象 | 工单 |
收货日期
标签 | 收货的日期 |
类型 | 日期 |
对象 | 工单 |
在系统配置(SysConfig)中设置:
'Ticket::Responsible': 是
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':
键: | 值: |
---|---|
书箱 | 标题, 作者, ISBN |
一般 | 状态 |
订单 | 价格, 供应商, 交货日期 |
运输 | 收货日期 |
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':
键: | 值: |
---|---|
作者 | 1 |
收货日期 | 1 |
交货日期 | 1 |
ISBN | 1 |
价格 | 1 |
状态 | 1 |
供应商 | 1 |
标题 | 1 |
现在我们可以开始真正的流程管理配置了。下一步,我们将定义所需的独立实体。
创建一个新流程,需要点击管理员面板中系统管理的"Process Management 流程管理",我们会进入流程管理概览窗口。在创建流程后,我们就可以创建其他全部实体(或流程组件)。
一个流程中所定义的Activitiy(活动)、Activity Dialog(活动对话框)、Transition(转换) 与 Transition Action(转换操作),都可以被系统中的所有流程使用。
点击左侧操作框的“创建新的流程”按钮。
填写流程信息、设置流程名与描述,我们在完成所有配置任务之前,我们先把流程状态设为“非活动”。
在流程管理概览窗口点击新建的流程名称,然后在“可用的流程元素”中点击“活动对话框”(点击会展开活动对话框选项,并收起其它具有可折叠效果的选项),再点击“创建新的活动对话框”。
在打开的弹出窗口中填写“活动对话框名称”和“描述(简短)”相同内容,本例中我们将其它字段都保持默认值,要给活动对话框分配字段,仅需从“可用的字段”池中拖动必填字段,并放到“分配的字段”池中即可。“分配的字段”池中的字段顺序为将字段放进去的先后顺序,可通过拖放操作进行字段重新排序。
将选择的字段拖入"分配的字段"池后,会弹出另一个窗口,显示该字段详细信息,保留默认选项即可,接着将信件字段的信件类型(ArticleType)字段设置为 "备注-内部"。
在所有字段都分配好之后,点击主弹出窗口的提交按钮,保存修改记录。
本例中,我们将使用信件字段来记录备注,但是可以用另外一个选项创建一个多行文本类型的动态字段,在下面的行中上述剩余的字段是我们之前定义好的动态字段。
请注意本窗口中的所有动态字段都有“DynamicField_”前缀如“DynamicField_Title”,不要与工单标题的字段“Title标题”搞混淆了,
创建如下活动对话框:
"记录需求" (AD1)
此活动对话框包含了订单所需的所有数据字段(标题、作者与ISBN号),以及一个标识审批状态的字段“审批”。
“审批拒绝” (AD2)
此活动对话框拥有一个用于注释的字段 (信件)与一个选择“审批拒绝”状态的字段“审批拒绝”。
“通过审批” (AD3)
只需要一个状态字段,选项为“通过审批”。
“采购拒绝” (AD4)
此活动对话框设计来拒绝一笔无效的采购单(书籍缺货)。这里同样需要一个注释字段与一个状态字段选项“采购拒绝”。
“生成订单” (AD5)
活动对话框中包含了采购涉及的供应商、价格与发货日期字段以及状态字段选项 “生成订单”。
“货品收到” (AD6)
此活动需要为收发室添加一个收到日期的字段,还需要一个状态字段选项“货品收到”。
为了限制每个活动对话框的状态字段值,我们需要在Kernel/Config.pm
或一个新的Perl文件Kernel/Config/Files
中添加一些ACL。
$Self->{TicketAcl}->{'P1-AD1-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD1'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approval'], }, }, }; $Self->{TicketAcl}->{'P1-AD2-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD2'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approval denied'], }, }, }; $Self->{TicketAcl}->{'P1-AD3-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD3'], }, }, Possible => { Ticket => { DynamicField_Status => ['Approved'], }, }, }; $Self->{TicketAcl}->{'P1-AD4-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD4'], }, }, Possible => { Ticket => { DynamicField_Status => ['Order denied'], }, }, }; $Self->{TicketAcl}->{'P1-AD5-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD5'], }, }, Possible => { Ticket => { DynamicField_Status => ['Order placed'], }, }, }; $Self->{TicketAcl}->{'P1-AD6-1'} = { Properties => { Process => { ActivityDialogEntityID => ['AD6'], }, }, Possible => { Ticket => { DynamicField_Status => ['Shipment received'], }, }, };
在“可用的流程元素”中点击“转换”, 接着点击“创建新的转换”。
在弹出窗口填写“转换名称”,接着我们需要配置条件选项,本例中只需要设置一个条件和一个字段,可以设置链接类型为“与”以及字段匹配类型值为“字符串”。
所有条件设置好后,点击提交按钮,保存结果。
创建如下转换:
“审批” (T1)
用于检查状态字段是否被设置为“审批”的转换。
“审批拒绝” (T2)
用于检查状态字段是否被设置为“审批拒绝”的转换。
“通过审批” (T3)
用于检查状态字段是否被设置为“通过审批”的转换。
“采购拒绝” (T4)
用于检查状态字段是否被设置为“采购拒绝”的转换。
“生成订单” (T5)
用于检查状态字段是否被设置为“生成订单”的转换。
“货品收到” (T6)
用于检查状态字段是否被设置为“货品收到”的转换。
点击“可用的流程元素”中的“转换操作”,接着点击“创建新的转换操作”。
在弹出窗口填写“转换操作名称”和“转换操作模块”,然后添加必填的和可选的参数名和参数值。
所有的转换操作模块位于文件Kernel/System/ProcessManagement/TransitionAction
中,下面是本版本中捆绑的转换操作清单:
DynamicFieldSet动态字段设置
TicketArticleCreate工单信件创建
工单创建
TicketCustomerSet工单客户设置
TicketLockSet工单锁定设置
TicketOwnerSet工单所有者设置
TicketQueueSet工单队列设置
TicketResponsibleSet工单负责人设置
TicketServiceSet工单服务设置
TicketSLASet工单SLA设置
TicketStateSet工单状态设置
TicketTitleSet工单标题设置
TicketTypeSet工单类型设置
每个模块都拥有其独立与不同的参数。请查阅module documentation 模块文档来了解所有必填与可选参数。
从OTRS 4.0.1开始,参数不再强制使用固定值,而是通过格式<OTRS_Ticket_property>从原始工单继承。
从OTRS 4.0.6开始支持格式<OTRS_TICKET_property>,老格式仍然可以使用,但是会在将来的版本中废弃。
当所有参数与数值都配置好后,点击提交按钮保存变更。
新建如下转换操作:
“将工单移入‘管理’队列” (TA1)
此动作预计在转换“审批” (T1)应用后执行。
“变更工单负责人为‘经理’ ” (TA2)
此动作在转换“审批” (T1)应用后执行。
“移动流程工单到‘员工’队列” (TA3)
当遇到如下情况时执行:
应用了转换“审批拒绝” (T2)
应用了转换 “采购拒绝” (T4)
应用了转换 “货品收到” (T6)
“变更工单负责人为‘员工’” (TA4)
当遇到如下情况时执行:
应用了转换“审批拒绝” (T2)
应用了转换 “采购拒绝” (T4)
应用了转换 “货品收到” (T6)
“将工单转入‘采购’队列” (TA5)
当应用了转换 “通过审批” (T3)时执行。
“移动工单至‘邮局’队列” (TA6)
当应用了“生成订单” (T5)时执行。
“工单成功关闭” (TA7)
当遇到如下情况时执行:
应用了转换“货品收到” (T6)
“工单失败关闭” (TA8)
当遇到如下情况时执行:
应用了转换“审批拒绝” (T2)
应用了转换 “采购拒绝” (T4)
正如你所见,相同的转换操作会在很多地方被执行。因此设计允许转换操作与转换自由连接,是为了更好的复用资源。
我们选择将活动(Activities)看作一个篮子,这个篮子可以包含一个或多个活动对话框(Activity Dialogs)。
点击“可用的流程元素”中的“活动”,接着点击“创建新活动”。
在打开的弹出窗口中填写“活动名称”,然后仅需从“可用的活动对话框”池中拖动需要的活动对话框,并放到“分配的活动对话框”池中即可。这些对话框会在工单详情窗口按本窗口定义的从上到下、从左到右的顺序显示出来。
在第一个活动中这个顺序特别重要,因为流程开始后唯一显示的就是这个活动的第一个活动对话框。
创建下列活动:
“记录需求” (A1)
包含活动对话框“记录需求” (AD1)
“审批” (A2)
包含活动对话框“审批拒绝” (AD2)和“通过审批” (AD3)
“订单” (A3)
包含活动对话框“采购拒绝” (AD4)与“生成订单” (AD5)
“即将到达” (A4)
包含活动对话框“货品收到” (AD6)
“流程结束” (A5): 这是一个没有活动对话框的活动。它需要被设置在“审批拒绝”、“采购拒绝”或者“货品收到”之后,代表流程结束。
现在我们可以清晰地看到,活动是一个流程工单精确定义的状态。在转换成功后,流程工单会从一个活动移动到另外一个。
让我们用拼图所缺失的最后一块来结束我们的示例-将流程作为流记录器。在我们的例子中,就是完整的订购工作流。其他流程可能还有办公用品订购或其他完全不同的流程。
此流程有一个起始点,它包括了初始活动和初始活动对话框。对于任何新书采购,初始活动对话框(第一个活动的第一个活动对话框)是最先显示的。如果这个活动完成并保存,流程工单将被创建并可以根据配置好的工作流进行处理。
流程中还包含了流程工单在流程中如何移动的方向。我们称之为“路径”。它由初始活动、一个或多个转换(可能包含转换操作)、以及其他活动组成。
假设该活动已经指派了相关的活动对话框,将其从折叠区域(屏幕的左侧部分)拖放到画布区域(在流程信息下面)。请注意,流程起始(绿色圆圈)会自动放置一个到该活动的箭头。(这是第一个活动,并且其第一个活动对话框会在流程开始后在窗口第一个显示)。
下一步,将另一个活动也拖放到画布中。现在画布中我们有了两个活动。第一个活动连接到起始点,第二个活动还没有连接。你可以将鼠标移动到活动上,会显示它们自己的活动对话框。
接下来让我们在这两个活动间创建“路径”(连接),创建路径需要使用转换。在折叠区域点击“转换”并拖动一个转换到第一个活动里面放下。注意活动变化了颜色,表示附上了转换。转换一放下,转换箭头的终点就放置在邻近流程的起始点位置。拖动转换的箭头终点到另一活动里面来创建这两个活动的连接。
现在操作之间的“路径”已经定义好了,接下来我们需要分配转换操作到这个转换上,在画布中双击转换标签,这会弹出新窗口。
从‘可用的转换操作’池中拖动所需的转换活动,并将其放置在‘分配的转换操作’池中,点击提交按钮。
接着回到流程编辑主窗口,点击画布下的保存按钮,保存所有其他的修改。
添加下列活动、转换和转换操作以完成“路径”:
记录需求直到“批准”
起始点:活动“记录需求” (A1)
可能的转换:“审批” (T1)
如果这个活动的条件满足,该工单将移动到活动“审批” (A2)
此外,还会执行下列的转换操作:
“将工单移入‘管理’队列” (TA1)
“变更工单负责人为‘经理’ ” (TA2)
活动:“记录需求” (A1)是流程工单预定义步骤,以确认转换:“审批” (T1)的可能性。如果适用,工单将移动到下一个活动:“审批” (A2),并且执行转换操作“移动到‘管理’队列” (TA1)和“变更工单负责人为‘经理’ (TA2)。在活动“审批” (A2)中,活动对话框“审批拒绝” (AD2) 和“通过审批” (AD3) 可用。
审批
起始点:活动“审批” (A2)
可能的转换:
“审批拒绝” (T2)
如果匹配这个,流程工单就移动到活动“流程结束” (A5)。
此外,还会执行下列的转换操作:
“移动流程工单到‘员工’队列” (TA3)
“变更工单负责人为‘员工’” (TA4)
“工单失败关闭” (TA8)
“通过审批” (T3)
如果匹配这个,流程工单就移动到活动“订购” (A3)。
此外,还会执行下面的转换操作::
“将工单转入‘采购’队列” (TA5)
我们可以看到,定义流程工单的当前活动有一个或多个转换的可能性,转换有一个目标活动(和可能的一个或多个转换操作)。
订单
起始点:活动“订购” (A3)
可能的转换:
“采购拒绝” (T4)
如果匹配这个,流程工单就移动到活动“流程结束” (A5)。
此外,还会执行下列的转换操作:
“移动流程工单到‘员工’队列” (TA3)
“设置工单负责人为‘员工’” (TA4)
“工单失败关闭” (TA8)
“生成订单” (T5)
如果匹配这个,流程工单就移动到活动“即将到达”
此外,还会执行下面的转换操作::
“移动工单至‘邮局’队列” (TA6)
即将到达
起始点:活动“即将到达” (A4)
可能的转换:
“货品收到” (T6)
如果匹配这个,流程工单就移动到活动“流程结束” (A5)。
此外,还会执行下列的转换操作:
“移动流程工单到‘员工’队列” (TA3)
“设置工单负责人为‘员工’” (TA4)
“工单成功关闭” (TA7)
书籍采购流程完整路径看上去就像这样:
在完成流程路径后,请点击画布正文的“保存”按钮,然后再点击“同步所有流程”按钮。这将收集所有的流程信息到数据库并创建一个缓存文件(用Perl语言)。这个缓存文件就是实际的流程配置,系统将用它来创建或处理流程工单。
任何流程变更(通过GUI界面)都需要重新同步缓存文件,才可以确保将变更映射到系统。
也可以从一个YAML文件导入整个流程,但是在导入前,仍然需要创建每个流程需要的所有动态字段、用户、队列等等。
注意:如果流程需要使用ACL,这些ACL也需要手动设置好。
下面是书籍采购流程示例的完整YAML文件内容:
--- Activities: A1: ActivityDialogs: - AD1 ChangeTime: 2012-11-23 14:49:22 Config: ActivityDialog: 1: AD1 CreateTime: 2012-11-23 11:49:38 EntityID: A1 ID: 151 Name: 记录需求 A2: ActivityDialogs: - AD2 - AD3 ChangeTime: 2012-12-13 00:55:12 Config: ActivityDialog: 1: AD2 2: AD3 CreateTime: 2012-11-23 11:50:11 EntityID: A2 ID: 152 Name: 审批 A3: ActivityDialogs: - AD4 - AD5 ChangeTime: 2012-11-23 18:12:14 Config: ActivityDialog: 1: AD4 2: AD5 CreateTime: 2012-11-23 11:50:35 EntityID: A3 ID: 153 Name: 采购 A4: ActivityDialogs: - AD6 ChangeTime: 2012-11-23 18:12:35 Config: ActivityDialog: 1: AD6 CreateTime: 2012-11-23 11:51:00 EntityID: A4 ID: 154 Name: 即将到达 A5: ActivityDialogs: [] ChangeTime: 2012-11-23 11:51:33 Config: {} CreateTime: 2012-11-23 11:51:33 EntityID: A5 ID: 155 Name: 流程结束 ActivityDialogs: AD1: ChangeTime: 2012-12-06 02:16:21 Config: DescriptionLong: '' DescriptionShort: 记录需求 FieldOrder: - DynamicField_Author - DynamicField_ISBN - DynamicField_Title - DynamicField_Status Fields: DynamicField_Author: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_ISBN: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Title: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: '' CreateTime: 2012-11-23 14:34:43 EntityID: AD1 ID: 154 Name: 记录需求 AD2: ChangeTime: 2012-11-23 14:57:41 Config: DescriptionLong: '' DescriptionShort: 审批拒绝 FieldOrder: - Article - DynamicField_Status Fields: Article: Config: ArticleType: note-internal DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: 拒绝请求 CreateTime: 2012-11-23 14:36:39 EntityID: AD2 ID: 155 Name: Approval denied AD3: ChangeTime: 2012-12-14 03:14:23 Config: DescriptionLong: '' DescriptionShort: 通过审批 FieldOrder: - DynamicField_Status Fields: DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: 同意请求 CreateTime: 2012-11-23 14:37:35 EntityID: AD3 ID: 156 Name: 通过审批 AD4: ChangeTime: 2012-11-23 14:58:52 Config: DescriptionLong: '' DescriptionShort: 采购拒绝 FieldOrder: - Article - DynamicField_Status Fields: Article: Config: ArticleType: note-internal DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: 拒绝采购 CreateTime: 2012-11-23 14:38:48 EntityID: AD4 ID: 157 Name: 采购拒绝 AD5: ChangeTime: 2012-12-06 02:20:12 Config: DescriptionLong: '' DescriptionShort: 生成订单 FieldOrder: - DynamicField_DeliveryDate - DynamicField_Price - DynamicField_Supplier - DynamicField_Status Fields: DynamicField_DeliveryDate: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Price: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Supplier: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Place Order CreateTime: 2012-11-23 14:41:28 EntityID: AD5 ID: 158 Name: 生成订单 AD6: ChangeTime: 2012-11-23 14:42:43 Config: DescriptionLong: '' DescriptionShort: 货品到达 FieldOrder: - DynamicField_DateOfReceipt - DynamicField_Status Fields: DynamicField_DateOfReceipt: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: '' CreateTime: 2012-11-23 14:42:43 EntityID: AD6 ID: 159 Name: 货品到达 Process: Activities: - A1 - A2 - A3 - A4 - A5 ChangeTime: 2012-12-06 02:31:59 Config: Description: 采购一本书的流程 Path: A1: T1: ActivityEntityID: A2 TransitionAction: - TA2 - TA1 A2: T2: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA8 T3: ActivityEntityID: A3 TransitionAction: - TA5 A3: T4: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA8 T5: ActivityEntityID: A4 TransitionAction: - TA6 A4: T6: ActivityEntityID: A5 TransitionAction: - TA3 - TA4 - TA7 A5: {} StartActivity: A1 StartActivityDialog: AD1 CreateTime: 2012-11-23 11:45:12 EntityID: P1 ID: 94 Layout: A1: left: 172 top: 63 A2: left: 402 top: 156 A3: left: 649 top: 255 A4: left: 774 top: 391 A5: left: 194 top: 410 Name: 书籍采购 State: Active StateEntityID: S1 TransitionActions: - TA1 - TA2 - TA3 - TA4 - TA8 - TA5 - TA3 - TA4 - TA8 - TA6 - TA3 - TA4 - TA7 Transitions: - T1 - T2 - T3 - T4 - T5 - T6 TransitionActions: TA1: ChangeTime: 2012-11-23 16:01:37 Config: Config: Queue: Management Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 15:50:59 EntityID: TA1 ID: 61 Name: 将工单转入‘管理’队列” TA2: ChangeTime: 2012-11-23 16:02:12 Config: Config: Responsible: 经理 Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 15:58:22 EntityID: TA2 ID: 62 Name: 变更工单负责人为‘经理’ TA3: ChangeTime: 2012-11-24 14:27:02 Config: Config: Queue: 员工 Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:02:54 EntityID: TA3 ID: 63 Name: 将工单转入‘经理’队列” TA4: ChangeTime: 2012-11-23 16:04:06 Config: Config: Responsible: 员工 Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 16:04:06 EntityID: TA4 ID: 64 Name: 变更工单负责人为‘员工’ TA5: ChangeTime: 2012-12-06 02:18:34 Config: Config: Queue: 采购 Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:04:54 EntityID: TA5 ID: 65 Name: 将工单转入‘采购’队列” TA6: ChangeTime: 2012-12-06 02:18:48 Config: Config: Queue: 邮局 Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:06:20 EntityID: TA6 ID: 66 Name: 将工单转入‘邮局’队列” TA7: ChangeTime: 2012-12-06 02:29:55 Config: Config: State: 成功关闭 Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet CreateTime: 2012-12-06 02:29:27 EntityID: TA7 ID: 67 Name: Close ticket successfully TA8: ChangeTime: 2012-12-06 02:31:12 Config: Config: State: closed unsuccessful Module: Kernel::System::ProcessManagement::TransitionAction::TicketStateSet CreateTime: 2012-12-06 02:31:12 EntityID: TA8 ID: 68 Name: 工单失败关闭 Transitions: T1: ChangeTime: 2012-11-23 15:12:20 Config: Condition: 1: Fields: DynamicField_Status: Match: Approval Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:53:52 EntityID: T1 ID: 94 Name: Approval T2: ChangeTime: 2012-11-23 15:12:50 Config: Condition: 1: Fields: DynamicField_Status: Match: Approval denied Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:54:26 EntityID: T2 ID: 95 Name: Approval denied T3: ChangeTime: 2012-11-23 15:13:29 Config: Condition: 1: Fields: DynamicField_Status: Match: 通过审批 Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:54:54 EntityID: T3 ID: 96 Name: 通过审批 T4: ChangeTime: 2012-11-23 15:14:08 Config: Condition: 1: Fields: DynamicField_Status: Match: 采购拒绝 Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:55:25 EntityID: T4 ID: 97 Name: Order denied T5: ChangeTime: 2012-11-23 18:30:33 Config: Condition: 1: Fields: DynamicField_Status: Match: 生成订单 Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:15 EntityID: T5 ID: 98 Name: 生成订单 T6: ChangeTime: 2012-11-23 15:15:30 Config: Condition: 1: Fields: DynamicField_Status: Match: 货品到达 Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:48 EntityID: T6 ID: 99 Name: 货品到达
一个流程就是工作流/流程的路径。路径上的路标可以是活动或转换(后面再讨论转换)。
流程配置可以放在文件Kernel/Config.pm
中,但强烈推荐创建一个新文件如Kernel/Config/Files/MyProcess.pm
。注意图形界面生成的文件为Kernel/Config/File/ZZZProcessManagement
,请一定不要使用这个文件名,否则在同步流程时会被覆盖。让我们来看一个示例流程配置(从流程缓存文件):
$Self->{'Process'} = { 'P1' => { Name => 'Book order', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', State => 'Active', StartActivity => 'A1', StartActivityDialog => 'AD1', Path => { 'A1' => { 'T1' => { ActivityEntityID => 'A2', }, }, 'A2' => { 'T2' => { ActivityEntityID => 'A3', }, }, }, }, 'P2' => { Name => 'IT order', CreateTime => '26-02-2012 13:37:00', CreateBy => '1', ChangeTime => '27-02-2012 13:37:00', ChangeBy => '1', State => 'Active', StartActivity => 'A2', StartActivityDialog => 'AD2', Path => { 'A2' => { 'T3' => { ActivityEntityID => 'A4', }, }, }, } };
定义的流程状态。可用值为:
‘激活’-可以在新的流程工单中使用的所有流程。
‘逐渐消失’-不能在新工单中使用,但是现有工单仍然在使用的流程。
‘未激活’-流程没有激活,不能在新工单或现有工单中使用。
路径包含了当前流程的活动及活动间可能的转换。还有在转换时发生的转换操作。这个方式控制了流程工单发生的路径。例如:
'A1' => { 'T1' => { ActivityEntityID => 'A2', }, 'T2' => { ActivityEntityID => 'A3', }, 'T3' => { ActivityEntityID => 'A4', TransitionAction => ['TA1', 'TA2'], }, },
如果一个流程工单在活动 'A1',它有三个可能的路径来获得另一活动。在转换'T1'到'T3',定义了流程工单必须满足移动(转换)到另一活动的条件。
如果在这个案例中流程工单的所有值和转换'T2'所需的动态字段都是正确的,这个工单就会从活动'A1'移动到'A3'。在提交了一个活动对话框之后,或者工单有了其它任何修改,工单会从当前活动检查可能的转换。如果有多个可能的转换,就使用第一个(基于TransitionID的数字排序)。
此外,还可以在路径配置中给转换分配转换操作。这些转换操作就是在成功转换后执行的模块。在示例流程中它们用数组表单方式分配,我们会在后面讨论这些细节。
一个活动包含一个或多个活动对话框并模拟流程中的一个‘步骤’。当前活动的所有活动对话框都会在工单详情窗口中显示,直到一个转换条件满足后才能使用它们。
让我们看一个活动配置样例:
$Self->{'Process::Activity'} = { 'A1' => { Name => 'Activity 1 optional', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', ActivityDialog => { 1 => 'AD1', }, }, 'A2' => { Name => 'Activity 2 optional', CreateTime => '16-02-2012 13:37:00', CreateBy => '1', ChangeTime => '17-02-2012 13:37:00', ChangeBy => '1', ActivityDialog => { 1 => 'AD5', 2 => 'AD6', 3 => 'AD1', }, }, };
一个活动对话框是一个特别的窗口,能在不同的活动中使用。
让我们看一个活动配置样例:
$Self->{'Process::ActivityDialog'} = { 'AD1' => { Name => 'ActivityDialog 1 optional', DescriptionShort => 'Basic info', DescriptionLong => 'Please insert the necessesary basic information for IT orders', CreateTime => '28-02-2012 13:37:00', CreateBy => '1', ChangeTime => '29-02-2012 13:37:00', ChangeBy => '1', Fields => { PriorityID => { DescriptionShort => 'Priority ID', DescriptionLong => 'Enter the priority here', Display => 2, }, }, FieldOrder => [ 'PriorityID' ], SubmitAdviceText => 'Note: If you submit the form...', SubmitButtonText => 'Send request', }, 'AD2' => { Name => 'ActivityDialog 2 optional', DescriptionShort => 'Basic info', DescriptionLong => 'Please insert the necessesary basic information for Book orders', CreateTime => '28-02-2012 13:37:00', CreateBy => '1', ChangeTime => '29-02-2012 13:37:00', ChangeBy => '1', Fields => { StateID => { DescriptionShort => 'State ID', DescriptionLong => 'Enter the state here', Display => 2, DefaultValue => '2', }, Queue => { DescriptionShort => 'Queue ID', DescriptionLong => 'Enter the queue here', Display => 2, DefaultValue => 'Raw', }, Title => { DescriptionShort => 'Title', DescriptionLong => 'Enter the title here', Display => 1, DefaultValue => 'Default Title', }, DynamicField_Anzahl => { DescriptionShort => 'Amount', DescriptionLong => 'Enter the amount here', Display => 2, DefaultValue => '4', }, }, FieldOrder => [ 'DynamicField_Anzahl', 'StateID', 'Queue', 'Title' ], SubmitAdviceText => 'Note: If you submit the form...', SubmitButtonText => 'Send request', }, };
包含所有能在活动对话框中显示的字段。目前能使用下列字段:
Title State StateID Priority PriorityID Lock LockID Queue QueueID Customer CustomerID CustomerNo CustomerUserID Owner OwnerID Type TypeID SLA SLAID Service ServiceID Responsible ResponsibleID PendingTime DynamicField_$FieldName # for all dynamic fields
单个字段配置的样例:
StateID => { DescriptionShort => 'State ID', DescriptionLong => 'Enter the state here', Display => 2, DefaultValue => '2', },
“信件”字段是一个特殊的例子。如果它出现在一个‘字段’配置中,活动对话框将包含一个完整的富文本编辑器,拥有主题字段并能处理附件。输入的文本会作为信件添加到工单并通过邮件发送。让我们看看信件字段配置的一个例子:
Article => { DescriptionShort => 'Please insert your comment here.', DescriptionLong => '', Display => 1, Config => { ArticleType => 'note-internal', LabelSubject => '', LabelBody => '', }, },
让我们看看这个字段的配置选项:
控制这个字段是否显示和/或必填,可能的值有:
‘0’:字段不可见。这在自动设置字段值时有用。这种情况下会保存配置的默认值。
‘1’:字段可见,但是可选的。
‘2’:字段可见,且是必填的。下列的字段只能为不可见或必填:
QueueID Queue State StateID Lock LockID Priority PriorityID Type TypeID
这个字段配置为可选的,并且用户没有提交值,当用户提交活动对话框时将使用默认值保存。
一个转换决定(基于配置的条件)使用流程中的哪一个路径,例如:一个流程工单移动到哪个活动对话框。
让我们看一个转换配置的样例:
$Self->{'Process::Transition'} = { 'T1' => { Name => 'Transition 1', CreateTime => '14-03-2012 13:37:00', # optional CreateBy => '1', # optional ChangeTime => '15-03-2012 13:37:00', # optional ChangeBy => '15-03-2012 13:37:00', # optional Condition => { Cond1 => { Fields => { StateID => { Type => 'String', Match => '1', }, }, }, }, }, 'T2' => { Name => 'Transition 2 optional', CreateTime => 'DATE', # optional CreateBy => 'USERID', # optional ChangeTime => 'DATE', # optional ChangeBy => 'USERID', # optional Condition => { Cond1 => { Queue => 'Raw', DynamicField_Farbe => '2', DynamicField_Anzahl => '1', }, }, }, };
包含这个转换生效所需的所有条件。例如:
Condition => { Type => 'and', Cond1 => { Type => 'and', Fields => { StateID => { Type => 'String', Match => '1', }, DynamicField_Marke => { Type => 'String', Match => 'VW', }, }, Cond2 => { Type => 'and', Fields => { Queue => { Type => 'String', Match => 'Raw', }, }, }, },
让我们看看这个条件配置的详细信息。
指定不同的条件元素互相连接的方式,可能的值有:
‘与’:这是默认类型。要使转换生效必须满足所有的条件。
‘或’:至少需要满足一个条件。
‘异或’:必须恰好满足一个条件,不能满足多个条件。
指定这个条件内单个字段的测试结果互相连接的方式,可能的值有:
‘与’:这是默认类型。这个条件内的所有字段测试结果必须都匹配。
‘或’:至少需要匹配一个字段。
‘异或’:必须恰好匹配一个字段的测试结果,不能匹配多个。
字段名的例子。可以使用下列工单字段:
Title State StateID Priority PriorityID Lock LockID Queue QueueID Customer CustomerID CustomerNo CustomerUserID Owner OwnerID Type TypeID SLA SLAID Service ServiceID Responsible ResponsibleID DynamicField_$FieldName # for all DynamicFields
当测试一个含有‘ID’(如SLAID)的字段时,这个字段的数据库ID将用于测试,而其它字段则使用实际值来测试。
确定字段测试的类型,可能的值有:
‘String字符串’:比较字段值和在'Match'中指定的字符串,如果完全相同就是匹配的。
'Hash哈希':比较字段值的哈希值和在'Match'中指定的哈希值。所有的哈希值必须一致才是匹配的。
'Array数组':比较字段值的数组和在'Match'中指定的数组。两个数据的清单值必须一致才是匹配的。
'Regex正则表达式':使用一个正则表达式来测试字段值,重点注意的是'Match'包含qr{}xms作为基本条件。实际的正则表达式是在大括号中间。
'Module模块':允许你使用一个Perl模块来进行条件检查。如果模块返回1,检查是匹配的。你可以在文件Kernel/System/ProcessManagement/TransitionValidation/ValidateDemo.pm
中找到一个示例模块。
转换操作是成功应用转换后触发的操作(当一个流程工单从一个活动移动到另一活动时)。这些转换操作用来对工单执行不同的变更,如变更工单的队列或所有者,你还可以创建你自己的转换操作来执行其它的复杂变更。
让我们看一个转换配置的样例:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Junk', UserID => 123, }, }, };
这个参数包含模块所需的所有设置。它的内容取决于使用的特定的转换操作模块。请参阅单独的模块文档以了解详细信息。在我们的示例中,只是必须指定队列。不过我们还需发送UserID参数。转换操作将使用给定的UserID来模拟用户执行。
转换操作在“配置”参数中UserID的用法可在所有的转换操作中使用(从OTRS 3.2.4版本之后)。在本示例中特别重要的是触发转换操作的用户(也就是UserID为123的用户)有没有移动工单到队列'Junk'的权限。
要重复使用转换操作模块,只需在配置中指定多个转换操作。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move Junk', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Junk', }, }, 'TA2' => { Name => 'Queue Move Raw', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Raw', }, }, };
这里使用了同一个模块来移到一个流程工单到队列'Raw',还有移到队列'junk'。一个特定转换使用的转换操作由流程配置中的‘路径’设置来确定。
OTRS自带了多个可在你的流程中使用的转换操作。在这里你可以找到它们的文档以及需要如何配置它们。
在一个流程工单中设置一个或多个动态字段,示例:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set DynamicField MasterSlave to Master and Approved to 1', Module => 'Kernel::System::ProcessManagement::TransitionAction::DynamicFieldSet', Config => { MasterSlave => 'Master', Approved => '1', }, }, };
‘Name名称’指定配置的转换操作的名称。
‘MasterSlave主从’和‘Approved通过审批’就像动态字段名称一样指定,这个转换操作设置它们的值为('Master' 和 '1')。
创建一个信件,并用于创建备注或邮件回复。
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Article Create Note Internal', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketArticleCreate', Config => { ArticleType => 'note-internal', # note-external(备注-外部)|phone(电话)|fax(传真)|sms(短信)|... # 不包括任何电子邮件类型 SenderType => 'agent', # agent(服务人员)|system(系统)|customer(客户) ContentType => 'text/plain; charset=ISO-8859-15', # 或可选的字符集和MIME类型(如'text/html; charset=UTF-8') Subject => 'some short description', # 必填项 Body => 'the message text', # 必填项 HistoryType => 'OwnerUpdate', # EmailCustomer(客户邮件)|Move(移动)|AddNote(添加备注)|PriorityUpdate(更新优先级)|WebRequestCustomer(客户网页请求)|... HistoryComment => 'Some free text!', From => 'Some Agent <email@example.com>', # 不是必填项但有用 To => 'Some Customer A <customer-a@example.com>', # 不是必填项但有用 Cc => 'Some Customer B <customer-b@example.com>', # 不是必填项但有用 ReplyTo => 'Some Customer B <customer-b@example.com>', # 不是必填项 InReplyTo => '<asdasdasd.12@example.com>', # 不是必填项但有用 References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # 不是必填项但有用 NoAgentNotify => 0, # 如果不想发送服务人员通知 AutoResponseType => 'auto reply', # auto reject(自动拒绝)|auto follow up(自动跟进)|auto reply/new ticket(自动回复/新工单)|auto remove(自动移除) ForceNotificationToUserID => [ 1, 43, 56 ], # 如果想要强制给一些人员发送通知 ExcludeNotificationToUserID => [ 43, 56 ], # 如果想要在发送通知时完全排除一些人员, # 清单中的人员也会从信件的收件人中移除, # 比ForceNotificationToUserID优先级高 ExcludeMuteNotificationToUserID => [ 43, 56 ], # 与ExcludeNotificationToUserID相同,但是只有发送通知时移除,服务人员仍然会显示在信件的收件人中。 }, }, };
‘Name名称’指定这个转换操作的名称。可以随意选择,但名称最好能体现转换操作的用途。
‘ArticleType信件类型’定义创建的信件的类型。可能的值有:电话、传真、短信、WEB请求、备注-内部、备注-外部和备注-报告。
‘SenderType发件人类型’定义信件发件人的类型。可能的值有:服务人员、系统、客户。
‘ContentType内容类型’定义信件的内容类型。可能的值有:‘text/plain; charset=ISO-8859-15纯文本’或其它有效的字符集和MIME类型。
‘Subject主题’定义信件主题,必填。
‘Body正文’定义信件的内容,必填。
‘HistoryType历史类型’定义历史条目的类型。可能的值有:添加备注、归档标志更新、退回、客户更新、服务人员邮件、客户邮件、升级响应时间通知之前、升级响应时间通知开始、升级响应时间结束、升级解决时间通知之前、升级解决时间通知开始、升级解决时间结束、升级更新时间之前、升级更新时间开始、升级更新时间结束、跟进、转发、锁定、循环保护、合并、杂项、转换、新工单、所有者更新、服务人员电话、客户电话、优先级更新、移除、负责人更新、发送服务人员通知、发送答复、发送自动跟进、发送自动拒绝、发送自动回复、发送客户通知、服务更新、设置挂起时间、SLA更新、状态更新、关注、系统请求、工单动态字段更新、添加工单链接、删除工单链接、工时管理、类型更新、解锁、取消关注、客户WEB请求。
‘HistoryComment历史注释’定义历史条目的内容。
'From发件人'、 'To收件人'、 'Cc抄送' 和 'ReplyTo回复'使用上面指定格式的邮件地址。
‘InReplyTo作为答复’和‘References参考’使用邮件消息ID。
‘NoAgentNotify无服务人员通知’-如果设置为1,不会发送服务人员的邮件通知。
‘AutoResponseType自动响应类型’可以使用下列的值:自动跟进、自动拒绝、自动移除、自动回复、自动回复/新工单。
‘ForceNotificationToUserID强制发送通知给UserID’、‘ExcludeNotificationToUserID为UserID排除通知’、‘ExcludeMuteNotificationToUserID为UserID排除静音通知’可以使用的UserID列表,给这些UserID的用户要么始终发送通知、不发送通知,要么加入发送清单但并不发送通知邮件。
创建一个有信件的工单,这个新工单能够链接到流程工单。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => '创建工单', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketCreate', Config => { # 工单必填项: Title => '工单标题', Queue => 'Raw队列', # 或队列ID QueueID => 123, Lock => '未锁定', Priority => '3-正常', # 或优先级ID PriorityID => 2, State => '新建', # 或状态ID StateID => 5, CustomerID => '123465', CustomerUser => 'customer@example.com', OwnerID => 'someuserlogin', # 或所有者ID OwnerID => 123, # 工单可选项: TN => $TicketObject->TicketCreateNumber(), # 可选项 Type => '故障', # 或类型ID TypeID => 1, 不是必填项 Service => '服务A', # 或服务ID ServiceID => 1, 不是必填项 SLA => 'SLA A', # 或 SLAID => 1, 不是必填项 ResponsibleID => 123, # 不是必填项 ArchiveFlag => 'y', # (y|n) 不是必填项 PendingTime => '2011-12-23 23:05:00', # 可选项 (用于挂起状态) PendingTimeDiff => 123 , # 可选项 (用于挂起状态) # 信件必填项: ArticleType => 'note-internal(备注-内部)', # note-external(备注-外部)|phone(电话)|fax(传真)|sms(短信)|... # 不包括任何电子邮件类型 SenderType => 'agent', # agent(服务人员)|system(系统)|customer(客户) ContentType => 'text/plain; charset=ISO-8859-15', # 或可选的字符集和MIME类型(如'text/html; charset=UTF-8') Subject => '一些简短描述', # 必填项 Body => '消息正文', # 必填项 HistoryType => 'OwnerUpdate(更新所有者)', # EmailCustomer(客户邮件)|Move(移动)|AddNote(添加备注)|PriorityUpdate(更新优先级)|WebRequestCustomer(客户网页请求)|... HistoryComment => 'Some free text!', #信件可选项: From => 'Some Agent <email@example.com>', # 不是必填项但有用 To => 'Some Customer A <customer-a@example.com>', # 不是必填项但有用 Cc => 'Some Customer B <customer-b@example.com>', # 不是必填项但有用 ReplyTo => 'Some Customer B <customer-b@example.com>', # 不是必填项 MessageID => '<asdasdasd.123@example.com>', # 不是必填项但有用 InReplyTo => '<asdasdasd.12@example.com>', # 不是必填项但有用 References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # 不是必填项但有用 NoAgentNotify => 0, # 如果不想发送服务人员通知 AutoResponseType => 'auto reply(自动回复)' # auto reject(自动拒绝)|auto follow up(自动跟进)|auto reply/new ticket(自动回复/新工单)|auto remove(自动移除) ForceNotificationToUserID => [ 1, 43, 56 ], # 如果想要强制给一些人员发送通知 ExcludeNotificationToUserID => [ 43,56 ], # 如果想要在发送通知时完全排除一些人员, # 清单中的人员也会从信件的收件人中移除, # 比ForceNotificationToUserID优先级高 ExcludeMuteNotificationToUserID => [ 43,56 ], # 与ExcludeNotificationToUserID相同,但是只有发送通知时移除,服务人员仍然会显示在信件的收件人中。 TimeUnit => 123 # 其它: DynamicField_NameX => $Value, LinkAs => $LinkType, # 普通、父、子等等(相对于原始工单) UserID => 123, # 可选,用于覆盖登录用户的UserID }, }, };
‘Name名称’指定这个转换操作的名称。可以随意选择,但名称最好能体现转换操作的用途。
‘Title标题’工单的标题。
‘Queue队列’或‘QueueID’指定用于新工单的队列名称或ID。
‘Lock锁定’或‘LockID’设置工单的锁定状态。
‘Priority优先级’或‘PriorityID’在新工单中指定优先级的名称或ID。
‘State状态’或‘StateID’在新工单中指定状态的名称或ID。
‘CustomerID客户ID’,为新工单设置客户ID。
‘CustomerUser客户联系人’,分配给工单的客户登录名。
'Owner(所有者)'或 'OwnerID(所有者ID)',指定新工单所有者的服务人员的登录名或ID。
‘TN’,新工单的客户编号。
‘Type类型’或‘TypeID’,指定用于新工单的工单类型名称或ID。
‘Service服务’或‘ServiceID’,指定用于新工单的服务名称或ID。
‘SLA’或‘SLAID’,指定用于新工单的SLA名称或ID。
‘ResponsibleID负责人ID’,新工单负责人的服务人员ID。
‘PendingTime挂起时间’,预先定义的当工单状态属于一种挂起状态类型时工单的挂起时间。
‘PendingTimeDiff挂起时间差’,当工单状态属于一种挂起状态类型时,给工单挂起时间设置一个动态时间(从当前时间按秒表示)。
‘ArticleType信件类型’定义创建的信件的类型。可能的值有:电话、传真、短信、WEB请求、备注-内部、备注-外部和备注-报告。
‘SenderType发件人类型’定义信件的发件人类型,可能的值有:服务人员、系统、客户。
‘ContentType内容类型’定义信件的内容类型。可能的值有:‘text/plain; charset=ISO-8859-15纯文本’或其它有效的字符集和MIME类型。
‘Subject主题’定义信件主题,必填。
‘Body正文’定义信件的内容,必填。
‘HistoryType历史类型’定义历史条目的类型。可能的值有:添加备注、归档标志更新、退回、客户更新、服务人员邮件、客户邮件、升级响应时间通知之前、升级响应时间通知开始、升级响应时间结束、升级解决时间通知之前、升级解决时间通知开始、升级解决时间结束、升级更新时间之前、升级更新时间开始、升级更新时间结束、跟进、转发、锁定、循环保护、合并、杂项、转换、新工单、所有者更新、服务人员电话、客户电话、优先级更新、移除、负责人更新、发送服务人员通知、发送答复、发送自动跟进、发送自动拒绝、发送自动回复、发送客户通知、服务更新、设置挂起时间、SLA更新、状态更新、关注、系统请求、工单动态字段更新、添加工单链接、删除工单链接、工时管理、类型更新、解锁、取消关注、客户WEB请求。
‘HistoryComment历史注释’定义历史条目的内容。
'From发件人'、 'To收件人'、 'Cc抄送' 和 'ReplyTo回复'使用上面指定格式的邮件地址。
‘InReplyTo作为答复’和‘References参考’使用邮件消息ID。
‘NoAgentNotify无服务人员通知’-如果设置为1,不会发送服务人员的邮件通知。
‘AutoResponseType自动响应类型’可以使用下列的值:自动跟进、自动拒绝、自动移除、自动回复、自动回复/新工单。
‘ForceNotificationToUserID强制发送通知给UserID’、‘ExcludeNotificationToUserID为UserID排除通知’、‘ExcludeMuteNotificationToUserID为UserID排除静音通知’可以使用的UserID列表,给这些UserID的用户要么始终发送通知、不发送通知,要么加入发送清单但并不发送通知邮件。
‘时间单位’花费在当前工单信件上的时间,按秒、分钟或小时等表示。
‘DynamicField_NameX’这里DynamicField_是必需的前缀,NameX是在新工单(在工单级而不是信件级)设置的动态字段的名称。
‘LinkAs链接为’用来定义新工单与原始工单的关系,从新工单角度看,有普通(链接)、父(链接)、子(链接)等等。
设置一个流程工单的客户。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Customer Set Customer to test', Module => 'Kernel::System::Process::TransitionAction::TicketCustomerSet', Config => { No => 'test', User => 'client-user-123', # or in other words # CustomerID => 'client123', # CustomerUserID => 'client-user-123', }, }, };
‘Name名称’指定配置的转换操作的名称。
‘No编号’或‘CustomerID客户ID’设置客户ID。
‘User用户’或‘CustomerUserID客户联系人ID’设置客户的(登录)用户名。
变更一个流程工单的锁定状态。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Lock to lock', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketLockSet', Config => { Lock => 'lock', # or LockID => 2, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Lock锁定’定义流程新的锁定状态。
‘LockID’定义新锁定状态的内部ID号。
变更一个流程工单的所有者。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Owner Set root@localhost', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketOwnerSet', Config => { Owner => 'root@localhost', # or OwnerID => 1, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Owner所有者’指定新所有者的登录名。
‘OwnerID’指定新所有者的内部ID号。
移动工单到目标队列。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move Raw', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Raw', # or # QueueID => '2', }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Queue队列’指定目标队列的名称。
‘QueueID队列ID’指定目标队列的内部ID号。
变更一个流程工单的负责人。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Responsible Set root@localhost', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet', Config => { Responsible => 'root@localhost', # or ResponsibleID => 1, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Responsible负责人’指定新负责人的登录名。
‘ResponsibleID负责人ID’指定新负责人的内部ID。
给一个流程工单分配一个服务。工单需要有一个客户,服务必须分配给那个客户。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MyService service', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketServiceSet', Config => { Service => 'MyService', # or ServiceID => 123, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Service服务’定义流程工单的新服务。需要服务的全名(如GramdFatherService::FatherService::SonService)。
‘ServiceID服务ID’定义新服务的内部ID号。
给一个流程工单分配一个服务级别协议。工单需要有一个服务,SLA(服务级别协议)必须分配给那个服务。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MySLA SLA', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketSLASet', Config => { SLA => 'MySLA', # or SLAID => 123, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘SLA’定义流程工单新的服务级别协议。
‘SLAID’定义新SLA的内部ID号。
变更一个流程工单的状态。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set State to open', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketStateSet', Config => { State => 'open', # or StateID => 4, PendingTimeDiff => 123, }, }, };
‘Name名称’指定配置的转换操作的名称。
‘State状态’定义流程工单新的状态。
‘StateID’定义新状态的内部ID号。
‘PendingTimeDiff挂起时间差’仅用于挂起类型的状态,定义相对时间差秒数(相对于转换操作的执行时间)以便设置工单挂起时间,例如3600意味着挂起时间是在转换操作执行后的1小时。
设置一个流程工单的标题。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Ticket Title to Ticket-title', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTitleSet', Config => { Title => 'Ticket-title', }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Title标题’指定工单的新标题。
设置一个流程工单的工单类型。例如:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Ticket Type to default', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTypeSet', Config => { Type => 'default', # or # TypeID => '1', }, }, };
‘Name名称’指定配置的转换操作的名称。
‘Type类型’指定工单类型的名称。
‘TypeID’指定工单类型的内部ID。
在ACL的帮助下,你可以在流程工单中限制可选择的值。另请参阅ACL参考以获取全部工单ACL语法的描述。
只可以在文件Kernel/Config.pm
中定义ACL。例如:
$Self->{TicketAcl}->{'001-ACL-ProcessProperties'} = { Properties => { Process => { ProcessEntityID => ['P1'], ActivityEntityID => ['A1'], ActivityDialogEntityID => ['AD1'], } }, Possible => { ActivityDialog => ['AD1', 'AD3'], }, PossibleNot => { ActivityDialog => ['AD3'], }, };
ACL规则的名称。ACL规则的更多的信息,请查阅ACL手册。
这部分用于检查是否必须应用一个ACL。如果指定了值,就是应用了ACL规则,可以使用下列值:
在这里你可以指定活动对话框ID清单。这个清单限制了在工单详情窗口提供给用户的可用活动对话框。
‘Possible 可能的’列出允许的活动对话框。上面示例的设置在配置的活动对话框清单中仅允许'AD1'和'AD3'。
‘PossibleNot 不可能的’列出不允许的活动对话框。在上面的示例中,这个设置从配置的活动对话框清单中移除'AD3'。
如果同时指定了‘Possible可能的’和‘PossibleNot 不可能的’,配置的活动对话框将首先用‘Possible可能的’过滤,在我们的示例中仅留下'AD1'和'AD3'。然后应用‘PossibleNot 不可能的’,过滤掉'AD3',所以最终只有'AD1'保留下来,显示为用户能够使用的可用活动对话框。
如果匹配了多个ACL规则,则计算所有匹配规则的交集来确定可能的活动对话框。例如:
配置的活动对话框:'AD1'、'AD2'、 'AD3'、 'AD4'、 'AD5'、 'AD6'、'AD7'。
$Self->{TicketAcl}->{'001-ACL-Status'} = { Properties => { Ticket => { Status => 'new', } }, Possible => { ActivityDialog => ['AD1', 'AD2', 'AD3', 'AD6', 'AD7'], }, }; $Self->{TicketAcl}->{'002-ACL-Queue'} = { Properties => { Ticket => { Queue => ['Raw'] } }, Possible => { ActivityDialog => ['AD2', 'AD3', 'AD4', 'AD7'], }, }; $Self->{TicketAcl}->{'003-ACL-Priority'} = { Properties => { Ticket => { Priority => ['3 normal'] } }, PossibleNot => { ActivityDialog => ['AD3', 'AD4'], }, };
如果一个流程工单的状态为‘new新建’、在‘Raw’队列且优先级为‘3 - 正常’,则会匹配所有的3条ACL规则。
第一条规则减少活动对话框,从'AD1'、'AD2'、 'AD3'、 'AD4'、 'AD5'、 'AD6'、'AD7'变成了'AD1'、'AD2'、 'AD3'、 'AD6'、'AD7',禁用了'AD4'和'AD5'。
第二条规则会进一步减少剩余的活动对话框。在我们的示例中,仅存'AD2'、 'AD3'、'AD7'。
现在第三条规则通过'PossibleNot 不可能的'会进一步减少这个清单。从清单中移除'AD3'。没有移除'AD4',因为它并没有在先前的清单中。最终,'AD2'和AD7'保留为用户能够使用的可用活动对话框。
还可以限制能够显示在“新流程工单”窗口的流程。这个功能与限制活动对话框类似,除了一点:ACL只能基于用户。
查看下面的示例:
$Self->{TicketAcl}->{'200-ACL-Process'} = { # match properties Properties => { User => { UserID => [2, 3], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };
$Self->{TicketAcl}->{'201-ACL-Process'} = { # match properties Properties => { User => { Group_rw => [ 'MyGroup' ], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };
$Self->{TicketAcl}->{'202-ACL-Process'} = { # match properties Properties => { User => { Role => [ 'MyRole' ], }, }, Possible => { Process => ['P1', 'P2', 'P3'], }, PossibleNot => { Process => ['P4'], }, };