Эта функция в OTRS Позволяет поделировать процессы (потоки работ/задач) в системе управления заявками. ГОсновная идея заключается в том, чтобы задать повторяющиеся процессы и делегировать части работы различным сотрудникам, а также управлять продолжением работы по процессу, в зависимости от определенных условий.
Давайте рассмотрим некий пример чтобы все было более наглядно и понятно. Мы будем рассматривать процесс покупки книги:
Прежде чем заказ будет размещен, запрос на литературу работником будет записан. Следующая книга нужна в нашем примере:
Title: Prozessmanagement für Dummies Autor: Thilo Knuppertz ISBN: 3527703713
Начальник отдела где работает работник должен решить что делать с заказом. В случае отказа, причина отказа должна быть записана старшим по должности. В случае одобрения заказ передается в отдел закупок.
Закупка, в данном случае, состоит в том, чтобы найти, где книга может быть заказана на лучших условиях. Если ее нет на рынке, это должно быть записано в заказе. В случае успешного размещения заказа, закупщик записывает поставщика, цену и дату поставки.
Если предположить что заявка действует в этом рабочем потоке как сопроводительный документ, который может принимать сообщения об изменениях, мы получаем полное представление о процессных заявках.
Проанализировав предыдущий пример мы можем выделить следующие пункты:
Возможности регистрации данных, назовем их Activity Dialogs/Диалоги Активности,
Проверки, которые могут автоматически реагировать на изменение данных, назовем Переходы,
изменения, которые могут быть применены для обработки заявки после успешного перехода обработки заявки, назовем их Transition Actions.
Также нам необходим дополнительный элемент, который не так очевиден:
Возможность предложить, чтобы более чем один Диалог Активности/Activity Dialog был доступен. В нашем примере это необходимо, когда менеджер должен иметь выбор между "Approve/Утвердить" and "Deny/Запретить". Назовем это Activity/Активность.
Теперь, введя понятия Activities/Активность, Activity Dialogs/Диалоги Активности, Transitions/Переходы и Transition Actions/Действия перехода, мы имеем все необходимые инструменты для построения отдельных этапов нашего примера. Что мы еще не определили, так это область в которой для каждого потока работ/ work-flow был бы задан порядок шагов. Назовем это Process/Процесс. Чтобы иметь возможность ссылаться на все эти сущности/понятия позже, дадим им краткие имена/аббревиатуры в скобках. Эти обозначения основаны на внутреннем механизме идентификации, называемом EntityIDs.
EntityIDs согласовываются с одной или двумя буквами (в зависимости от части процесса), а затем порядковый номер, например:
Процесс: 'P1', 'P2' ... 'Pn'.
Деятельность: 'A1', 'A2' ... 'An'.
Диалог Активности: 'AD1', 'AD2' ... 'ADn'.
Переход: 'T1', 'T2' ... 'Tn'.
Переход действий: 'TA1', 'TA2' ... 'TAn'.
Перед созданием процесса и его частей необходимо подготовить систему. Нужно определить некоторые Очереди, Клиентов и Динамические Поля, а также установить некоторые опции в файле SysConfig.
Создать следующие Очереди:
Управление
Сотрудники
Покупка
Почтовое отделение
Создает следующих Пользователей:
Менеджер
Сотрудник
Создать следующие Динамически Поля:
Название
Метка | Название |
Type | Text |
Объект | Заявк |
Автор
Метка | Автор |
Type | Text |
Объект | Заявк |
ISBN
Метка | ISBN |
Type | Text |
Объект | Заявк |
Состояние
Метка | Состояние |
Type | Dropdown |
Объект | Заявк |
Возможные значения |
|
Примечание: Используйте именно эти возможные значения для "Ключ" и "Значение" при создании динамических полей.
Поставщик
Метка | Поставщик |
Type | Text |
Объект | Заявк |
Цена
Метка | Цена |
Type | Text |
Объект | Заявк |
DeliveryDate
Метка | Дата доставки |
Type | Date |
Объект | Заявк |
DateOfReceipt
Метка | Дата получения |
Type | Date |
Объект | Заявк |
Устанавливает следующие параметры SysConfig:
'Ticket::Responsible': Yes
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':
Ключ: | Содержание: |
---|---|
Книга | Название, Автор, ISBN |
Общий | Состояние |
Заказ | Цена, Поставщик, Дада доставки |
Отгрузка | DateOfReceipt |
'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':
Ключ: | Содержание: |
---|---|
Автор | 1 |
DateOfReceipt | 1 |
DeliveryDate | 1 |
ISBN | 1 |
Цена | 1 |
Состояние | 1 |
Поставщик | 1 |
Название | 1 |
Теперь давайте перейдем к описанию реального процесса. На следующем шаге мы определим конкретные объекты, которые нам необходимы.
Для создания нового процесса необходимо перейти к пункту Управление процессами на панели Администратора, после нажатия на который мы попадем на экран Обзора процессов. После создания процесса мы получим возможность создания всех его объектов (всех составляющих процесса).
Деятельности, Диалоги Активности, Переходы и Действия переходов определенные в одном процессе будут доступны для всех процессов системы.
Рисунок: Страница Администратора OTRS - Администрирование системы.
Нажмите на действие "Создать Новый Процесс" в окне Действий.
Figure: Создать кнопку Новый Процесс.
Заполняем информацию о процессе, указываем Название Процесса и его Описание, а статус оставим со значением "inactive", пока не закончим все задачи. Сохраняем процесс.
Рисунок Добавить новый процесс.
Кликните по имени процесса в окне Обзора процессов, затем в списке "Доступные элементы процесса" нажмите на "Диалоги Активности" (это действие распахнет список опций для диалогов активности и сожмет другие списки, к нему не относящиеся, напоминает эффект гармошки), затем нажмите на "Создать новый Диалог Активности".
Рисунок: Создать кнопку Новый Диалог Деятельности.
Во вновь открывшемся окне, заполните поле "Имя Диалога Активности", а также "Описание (краткое)", для этого примера мы оставим остальные поля со значениями по умолчанию. Для назначения полей Диалогу Активности просто захватите мышкой нужное поле из списка "Доступные поля" и перенесите в список "Назначенные поля". Их порядок в списка "Назначенные поля" будет соответствовать их порядку на экране. Для изменения порядка просто захватите мышкой нужное поле и переместите его в нужное место.
Figure: Добавить новый Диалог Деятельности.
После того как помещены в список "Назначенные поля", другое всплывющее окно покажет некоторые данные о поле. Мы оставим им всем умалчиваемые значения и только для полей типа Сообщение/Заметка мы долны проверить, что они имеют тип "note-internal".
Figure: Edit field details (Article).
Если все поля привязаны, нажмите на кнопку отправить в главном всплывающем окне чтобы изменения вступили в силу.
В этом примере мы будем использовать поля типа Article для комментариев, другой способ состоит в том, чтобы создать динамическое поле типа TextArea. Оставшиеся из упомянутых полей в строках ниже это динамические поля которые мы задали ранее.
Обратите вниманиче что на этой странице все Динамические Поля имеют префикс "DynamicField_" как в "DynamicField_Title", не путайте с полем "Название", которое является Названием Заявки.
Создать следующие Диалоги Активности:
"Запись спроса" (AD1)
Диалог Активности, который содержит все требуемые поля для хранения данных о заказе (Название, Автор и ISBN) и поле Состояние/Status с возможностью выбора "Утверждение".
"Отказать" (AD2)
Диалог Активности с полем комментария и полем статуса с опцией "Отказать".
"Утвержден" (AD3)
Здесь нам просто нужно поле статуса с опцией "Approved/Утверждено".
"Заказ отменен" (AD4)
Диалог Активности который позволяет отказаться от покупки (книги нет на складе). Здесь нам также потребуется поле с комментарием и поле статус со значением "Заказ отменен".
"Заказ размещен" (AD5)
Диалог Активности с полями Поставщик, Цена и Дата доставки для покупки и поле статуса со значением "Заказ размещен".
"Поставка получена" (AD6)
Диалог Активности для почтового отделения с полем для Даты получения и полем статуса со значением "Поставка получена".
Чтобы ограничить поле состояние для каждого из диалогов активности нам необходимо добавить некоторые ACL-права в файл Kernel/Config.pm или в новый perl-файл в Kernel/Config/Files.
$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'], }, }, };
В "Доступные Элементы Процесса" щелкните "Переходы", а затем кликните на "Создать новый переход".
Figure: Создать кнопку Новый Переход.
В открывшемся всплывающем окне заполните "Transition Name/Имя Перехода", затем, в условиях, для этого примера мы будем использовать только одно условие и только одно поле, для обоих мы оставим Type of Linking/Тип связывания "and/И", а также будем использовать тип значения поля для сравнения - "String".
Рисунок: Добавить новый ПереходAdd new Transition.
Когда все условия установлены, нажмите кнопку Отправить, чтобы сохнанить изменения.
Создать следующие Переходы:
"Утверждение" (T1)
Переход, который проверяет, установлен ли статус поля в "Approval".
"Отказано в утверждении" (T2)
Переход проверяющий установку статуса поля в значение "Approval denied".
"Утвержден" (T3)
Переход, проверяющий установку статуса поля в значение "Approved".
"Заказ отменен" (T4)
Переход проверяющий установку статуса поля в значение "Order denied".
"Заказ размещен" (T5)
Переход проверяющий установку статуса поля в значение "Order denied".
"Поставка получена" (T6)
Переход, который проверяет установлено ли поле статуса в значение "Shipment received".
Кликните на "Действия Переходов " в меню "Доступные элементы процесса", а затем кликните "Создать Новое Действие Перехода".
Рисунок: Кнопка создания нового перехода .
В открывшемся всплывающем окне заполните поле "Название Перехода" и "Модуль Деятельности Перехода", а затем добавьте требуемые и опциональные параметры, названия и значения.
Все Модули Переходов Действий находятся в Kernel/System/ProcessManagement/TransitionAction и ниже приводится список Переходов Действий включенных в этот релиз
DynamicFieldSet
TicketArticleCreate
TicketCreate
TicketCustomerSet
TicketLockSet
TicketOwnerSet
TicketQueueSet
TicketResponsibleSet
TicketServiceSet
TicketSLASet
TicketStateSet
TicketTitleSet
TicketTypeSet
Каждый модуль имеет свои собственные и другие параметры, пожалуйста просмотрите документацию к этому модулю module documentation, чтобы узнать все обязательные и опциональные параметры.
Начиная с OTRS 4.0.1, параметры теперь необязательно имеют фиксированные значения, но, вместо этого, они могут наследовать их из оригинальной заявки используя формат: <OTRS_Ticket_property>.
Начиная с версии OTRS 4.0.6, поддерживается формат <OTRS_TICKET_property>, старый формат тоже может использоваться, но не рекомендуется, так как будет отменен в будущих версиях.
Рисунок: Добавить новый переход деятельности.
Как только все параметры и значения установлены, нажмите кнопку отправить чтобы изменения вступили в силу.
Создать следующие Переходы:
"Переместить обработку Заявки в очередь 'Менеджмент' " (TA1)
Предполагается, что это действие будет выполнено когда применен Переход "Утверждение" (T1).
"Изменяет ответственного за заявку на 'manager'" (TA2)
Будет выполнено когд применен Переход "Approval" (T1).
"Перемещает процесс обработки заявки в очередь 'Employees' "" (TA3)
Будет выполнено когда:
Применение Перехода "Отказано в утверждении" (T2)
Применение Перехода "Order denied" (T4)
Применение Перехода "Поставка получена" (T6)
"Изменить ответственного за заявку на 'Employee'" (TA4)
Будет выполнено когда:
Применен переход "Отказано в утверждении" (T2)
Применен переход "Заказ отменен" (T4)
Применен переход "Поставка получена" (T6)
"Перемещает обработку Заявки в очередь 'Purchasing' " (TA5)
Будет выполнено когда применен Переход "Утверждено" (T3).
"Перемесить процессную заявку в очередь "Post office" " (TA6)
Будет выполнено когда применен Переход "Заказ размещен" (T5).
"Закрыть Заявку со статусом успешно" (TA7)
Будет выполнено когда:
Применен переход "Поставка получена" (T6)
"Закрыть заявку со статусом не успешно" (TA8)
Будет выполнено когда:
Применен переход "Отказано в утверждении" (T2)
Применен переход "Заказ отменен" (T4)
Как можно видеть, есть места, где одинаковые Transition Actions/Действия Перехода будут выполняться. Таким образом было бы логично сделать возможным связывать Transition Actions свободно с Transitions/Переходами, для их повторного использования.
Мы выбрали такой подход чтобы рассматривать Деятельности в качестве корзины, которая может хранить однин или больше Диалогов Деятельности. Нам нужны эти действия в нашем примере:
Кликните на "Деятельности" в меню "Доступные Элементы Процесса", а затем кликните на "Создать новую Деятельность".
Рисунок: Создание кнопки New Activity/Новая Активность.
В открывшемся всплывающем окне заполните "Activity Name/Имя Активности", затем захватите мышкой требуемые Activity Dialogs/Диалоги Активности из списка "Available Activity Dialogs/Доступные Диалоги Активности" и перетащите их в список "Assigned Activity Dialogs/Назначенные Диалоги Активности". Эти диалоги будут отображаться (на экране подробного просмотра заявки) с таком же порядке как это было задано на этом экране - лексикографически, т.е. сверху вниз, слева направо.
Такой порядок особенно важен в первой Деятельности, так как первый Диалог Деятельности для этой Деятельности является единственным, который находится при запуске процесса
Создать следующие Деятельности:
"Recording the demand/Запись запроса" (A1)
Содержит Activity Dialog/Диалог Активности "Recording the demandЗапись запроса" (AD1)
"Approval/Утверждение" (A2)
Содержит Диалоги Активности "Отказано в одобрении" (AD2) а также "Утвержден" (AD3)
"Заказ" (A3)
Содержит Диалоги Активности "Заказ отклонен" (AD4) а также "Заказ размещен" (AD5)
"Входящие" (A4)
Содержит Activity Dialog/Диалог Активности "Shipment received/Посылка получена" (AD6)
"Process complete/Процесс завершен" (A5): Это Activity/Действие без возможных Activity Dialogs/Диалогов Активности. Оно должно быть вставлено после "Approval denied/Не утверждено", "Order denied/Заказ отвергнут" или "Shipment received/Посылка получена" и указывает на окончание процесса.
Теперь мы можем видеть, что Деятельность точно определяет сосотояние процесса Заявки. После успешного Перехода Заявка перемещается из одного вида деятельности в другой.
Давайте закончим наш пример с последней недостающей частью головоломки - Процессом, как описанием потока работ. В нашем случае это весь рабочий процесс заказа. Другие процессы могут быть похожими, типа заказа офисных принадлежностей, или совершенно иными.
Процесс имеет начальную точку, состоящую из стартового Activity/Действия и стартового Activity Dialog/Диалога активности. Для любого нового заказа книги, начальный Activity Dialog/Диалог активности (первый диалог для первого Действия) является первым отображаемым экраном. Если он завершен и сохранен, будет создаваться новая процессная заявка, которая далее будет выполняться в соответствии с заданным потоком работ/work-flow.
Процесс также содержит указания, как процессная заявка будет продвигаться внутри Процесса. Назовем это "Path/Схема". Она состоит из начального Activity/Действия, одного или более Transitions/Переходов (возможно, с Transition Actions/Действиями переходов) и других Activities/Действий.
Предполагая, что эти Активности/Activities уже назначены их Диалогам/Activity Dialogs, перетащите Активность из "гармошки" (в левой части экрана) и поместите на область схемы (ниже информации о процессе). Заметьте, что стрелка от начала процесса (зеленый кружок) к Активности будет проложена автоматически. (Это первая Активность и ее первый Диалог будет первым экраном, который будет показан при старте Процесса).
Рисунок: Помещение первой Активности на полотно схемы.
Затем, перетащите следующую Активность на схему, таким же образом. Теперь, мы имеем две Активности на схеме, первая имеет соединение с точкой начала Процесса, а вторая пока не имеет соединений. Вы можете навести курсор мыши на каждую Активность, чтобы отобразить их собственный Диалог Активности.
Рисунок: Помещение второй Активности на полотно схемы.
Теперь, давайте создадим "Path" (соединение) между двумя Активностями, для чего используем Переходы/Transitions. Кликните по Переходу на "гармошке", перетащите его на схему и отпустите внутри первой Активности, обратите внимание что значок Активности изменил цвет, показывая этим, что Переход присоединен. Как только вы отпустите мышь конец стрелки Перехода будет помещен рядом с точкой начала Процесса. Перетащите конец стрелки Перехода и опустите его внутри значка другой Активности для создания соединения между Активностями.
Рисунок: Перетащите Transition/Переход на полотно схемы.
Теперь, когда "Path/Последовательность" Действий задана - необходимо назначить Действия Переходов/Transition Actions для Переходов/Transition. Двойной щелчок по имени Перехода (на схеме) откроет новое дополнительное окно.
Рисунок: Связать Активности используя Переходы.
Захватите мышью требуемые Активности Перехода из списка Доступных Активностей Перехода и перетащите в список Назначенных Активностей Перехода и затем нажмите кнопку Отправить.
Рисунок: Назначение Действий Перехода.
Затем, вернитесь к главному окну редактирования Процесса и нажмите кнопку Сохранить под схемой и сохраните все сделанные изменения.
Завершите "путь" добавляя следующие Активности, Переходы и Действия Переходов:
Запись спроса до значения "Approval"
Начальная точка: Activity: Запись запроса (A1)
Возможный Переход: Утверждение (T1)
Если условие этой Активности выполняется, заявка будет перемещена к Активность: Утверждение (A2)
Кроме того выполнится следующее действие TransitionActions:
"Переместить заявку в очередь 'Менеджмент' " (TA1)
"Назначить ответственным за заявку 'manager'" (TA2)
Активность: "Запись запроса" (A1) это определенный этап процессной заявки, который имеет возможные Переходы: "Approval/Утверждение" (T1). После выполнения, заявка переходит к следующей Активности: "Approval/Утверждение" (A2), и Действия Перехода: "Moving the ticket into the 'Management' Queue/Перемещение заявки в очередь 'Management' " (TA1) и "Set ticket responsible to 'manager'/Назначение ответственным 'manager'" (TA2) выполняются. В Активности: "Approval" (A2), доступны Диалоги: "Approval denied/Отказано" (AD2) and "Approved/Согласовано" (AD3).
Утверждение
Начальная точка: Activity/Активность "Approval/Утверждение" (A2)
Возможные Транзакции:
"Отказано в утверждении" (T2)
Если верно, процессная заявка перейдет к Activity/Действию:"Process complete/Процесс завершен" (A5).
Кроме того выполнится следующее TransitionActions/Действия Перехода:
"Переместить процессную заявку в очередь 'Employees'" (TA3)
"Установить ответственного за заявку в 'Employee'" (TA4)
"Закрыть заявку со статусом не успешно" (TA8)
"Утвержден" (T3)
Если верно, процессная заявка перейдет к Activity/Действию: "Order/Заказ" (A3).
Дополнительно, следующие Transition Action/Действия Перехода будут выполнены:
"Переместить процессную заявку в очередь 'Purchasing'" (TA5)
Можно видеть, что текущая Activity/Активность, которая определяет шаг процессной заявки имеет одну или более возможностей для Transition/Перехода, который, в свою очередь, имеет одну единственную целевую Activity/Активность (и, возможно, одно или более Transition Actions/Действие Перехода).
Заказ
Начальная точка: Activity/Активность "Order/Заказ" (A3)
Возможные Транзакции:
"Заказ отменен" (T4)
Если верно, процессная заявка перейдет к Activity/Действию:"Process complete/Процесс завершен" (A5).
Кроме того выполнится следующее TransitionActions/Действия Перехода:
"Переместить процессную заявку в очередь 'Employees'" (TA3)
"Установить ответственного за заявку в 'Employee'" (TA4)
"Закрыть заявку со статусом не успешно" (TA8)
"Заказ размещен" (T5)
Если верно, процессная заявка перейдет к Activity/Действию: "Incoming/Поступление" (A5).
Дополнительно, следующие Transition Action/Действия Перехода будут выполнены:
"Переместить процессную заявку в очередь 'Post office' " (TA6)
Входящие
Начальная точка: Activity/Действие: "Incoming/Поступление" (A4).
Возможные Транзакции:
"Поставка получена" (T6)
Если верно, процессная заявка перейдет к Activity/Действию:"Process complete/Процесс завершен" (A5).
Кроме того выполнится следующее TransitionActions/Действия Перехода:
"Переместить процессную заявку в очередь 'Employees'" (TA3)
"Установить ответственного за заявку в 'Employee'" (TA4)
"Закрыть Заявку со статусом успешно" (TA7)
Полный путь к Процессу покупкпи книги будет иметь следующий вид:
Рисунок: Полная схема процесса заказа книги.
Псоле окончания прорисовки Процесса нажмите кнопку "Сохранить", в нижней части схемы и затем, нажмите "Синхронизировать все процессы". При этом вся информация по процессам будет собрана из базы данных и будет создан кэш-файл (на языке Perl). Этот файл содержит конфигурацию процессов, которая будет использоваться для создания и обработки процессных заявок.
Все изменения сделанные в Процессе (в интерфейсе админа) потребуют пересинхронизации файла кэша, чтобы изменения были отражены в системе.
Также, возможно импортировать процесс целиком из YAML файла, но обязательно до этого создать все динамические поля, пользователей, очереди и пр. необходимые для каждого процесса.
Обратите внимание, что если процесс требует использования 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: Recording the demand 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: Approval 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: Order 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: Incoming A5: ActivityDialogs: [] ChangeTime: 2012-11-23 11:51:33 Config: {} CreateTime: 2012-11-23 11:51:33 EntityID: A5 ID: 155 Name: Process complete ActivityDialogs: AD1: ChangeTime: 2012-12-06 02:16:21 Config: DescriptionLong: '' DescriptionShort: Recoding the demand 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: Recording the demand AD2: ChangeTime: 2012-11-23 14:57:41 Config: DescriptionLong: '' DescriptionShort: Approval denied 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: Deny Request 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: Approved FieldOrder: - DynamicField_Status Fields: DynamicField_Status: DefaultValue: '' DescriptionLong: '' DescriptionShort: '' Display: 1 Interface: - AgentInterface Permission: '' RequiredLock: 0 SubmitAdviceText: '' SubmitButtonText: Approve Request CreateTime: 2012-11-23 14:37:35 EntityID: AD3 ID: 156 Name: Approved AD4: ChangeTime: 2012-11-23 14:58:52 Config: DescriptionLong: '' DescriptionShort: Order rejected 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: Reject Order CreateTime: 2012-11-23 14:38:48 EntityID: AD4 ID: 157 Name: Order rejected AD5: ChangeTime: 2012-12-06 02:20:12 Config: DescriptionLong: '' DescriptionShort: Order placed 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: Order placed AD6: ChangeTime: 2012-11-23 14:42:43 Config: DescriptionLong: '' DescriptionShort: Shipment received 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: Shipment received Process: Activities: - A1 - A2 - A3 - A4 - A5 ChangeTime: 2012-12-06 02:31:59 Config: Description: The process to order a book 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: Book ordering 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: Move the process ticket into the "Management" queue TA2: ChangeTime: 2012-11-23 16:02:12 Config: Config: Responsible: manager Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 15:58:22 EntityID: TA2 ID: 62 Name: Change ticket responsible to "manager" TA3: ChangeTime: 2012-11-24 14:27:02 Config: Config: Queue: Employees Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:02:54 EntityID: TA3 ID: 63 Name: Move the process ticket into the "Employees" queue TA4: ChangeTime: 2012-11-23 16:04:06 Config: Config: Responsible: Employee Module: Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet CreateTime: 2012-11-23 16:04:06 EntityID: TA4 ID: 64 Name: Change ticket responsible to "Employee" TA5: ChangeTime: 2012-12-06 02:18:34 Config: Config: Queue: Purchasing Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:04:54 EntityID: TA5 ID: 65 Name: Move process ticket into the "Purchasing" queue TA6: ChangeTime: 2012-12-06 02:18:48 Config: Config: Queue: Post office Module: Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet CreateTime: 2012-11-23 16:06:20 EntityID: TA6 ID: 66 Name: Move process ticket into the "Post office" queue TA7: ChangeTime: 2012-12-06 02:29:55 Config: Config: State: closed successful 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: Close ticket unsuccessfully 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: Approved Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:54:54 EntityID: T3 ID: 96 Name: Approved T4: ChangeTime: 2012-11-23 15:14:08 Config: Condition: 1: Fields: DynamicField_Status: Match: Order denied 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: Order placed Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:15 EntityID: T5 ID: 98 Name: Order placed T6: ChangeTime: 2012-11-23 15:15:30 Config: Condition: 1: Fields: DynamicField_Status: Match: Shipment received Type: String Type: and ConditionLinking: and CreateTime: 2012-11-23 11:56:48 EntityID: T6 ID: 99 Name: Shipment received
Процесс моделирует путь прохождения задач процесса. Путевыми точками на этом пути могут быть Активности или Переходы, мы расскажем об этом позже.
Конфигурация процесса может быть выполнена в файле
Kernel/Config.pm
, но мы настоятельно рекомендуем
создать новый файл
Kernel/Config/Files/MyProcess.pm
. Заметьте, что
генератор процессов в GUI создает файл
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', }, }, }, } };
Задает состояние процесса. Возможные значения:
'Active' / Активный - все процессы, которые могут быть использованы в новых процессных заявках.
'FadeAway' / Исчезающие - это процессы, которые нельзя выбрать более для новых заявок, но существующие заявки могут продолжать их использовать.
'Inactive' / Неактивные - деактивированные процессы. Они не могут быть более использованы ни в новых, ни в существующих заявках.
При создании новой процессной заявки, StartActivity / Начальная Активность должна быть задана.Как только заявка будет создана, эта Активность будет инициирована и использована как начальная точка для первых проверок переходов.
Для новой процессной заявки должен быть задан StartActivityDialog/Начальный Диалог Активности. Он будет показан при создании новой процессной заявки (после выбора процесс). В этот момент заявка еще не существует, она будет создана после выполнения StartActivityDialog.
Схема отображает структуру Активностей и возможных Переходов между ними для текущего процесса. А также Действия Переходов/Transition Actions возможные при переходах. Она показывает пути выполнения процессной заявки. Например:
'A1' => { 'T1' => { ActivityEntityID => 'A2', }, 'T2' => { ActivityEntityID => 'A3', }, 'T3' => { ActivityEntityID => 'A4', TransitionAction => ['TA1', 'TA2'], }, },
Если процессная заявка в состоянии Activity 'A1', она имеет три возможных пути перехода к другой Активности. Для Переходов от 'T1' до 'T3' заданы условия, которые процессная заявка должна выполнить для перехода (transit) к следующей Активности.
Если, в этом случае, все значения процессной заявки и ее динамических полей, которые необходимы для Перехода 'T2' верны, заявка перейдет от Активности 'A1' к 'A3'. После выполнения Диалога Активности или других изменений в заявке, будут проверены возможные Переходы от текущей Активности. Если доступны несколько Переходов - начнет выполнятся первый из них (порядок Переходов основан на цифровом значении TransitionIDs, по возрастанию).
Дополнительно, имеется возможность назначить Действия Переходов при конфигурации Процесса. Это модули, которые будут выполняться после успешного Перехода. Они должны быть заданы в виде массива/таблицы, как в примере, подробности этого мы обсудим позже.
Активность содержит один или более Диалог Активности и представляет собой этап Процесса. Все Диалоги Активности отображаются на экране подробного просмотра заявки TicketZoom и используются, пока условия Перехода выполняются.
Давайте рассмотрим пример конфигурации активности:
$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/Сообщение" это отдельный случай. Если оно присутствует в конфигурации "Fields/Поля", Диалог Активности будет содержать полноценный Richtext редактор, с полем Тема и возможностью управления вложениями. Введенный текст будет добавлен к заявке в качестве сообщения/заметки и отправлен почтой. Давайте рассмотрим пример конфигурации поля Сообщение:
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
Если поля заданы как необязательные, и никакие значения не вводятся пользователем, умалчиваемое значение будет присвоено этому полю, когда пользователь нажимает Отправить для этого Диалога Активности.
Для полей с суффиксом "ID" (таких как QueueID, OwnerID), система использует идентификатор в базе данных в качестве значения. Для других полей без "ID" (таких как Queue, Owner), значение по умолчанию должно содержать собственно значение. Например:
Queue => { DescriptionShort => 'Queue', DescriptionLong => 'Enter the queue here', Display => 2, DefaultValue => 'Raw', },
Здесь задается порядок отображения полей. ВАЖНО: Неотображаемые поля также должны быть заданы здесь, т.к. только описанные поля учитываются при сохранении. Значения полей не указанных здесь, не сохраняются.
Необязательный текст, отображаемый поверх указателя мыши при наведении на кнопку, содержит дополнительную подсказку или поясняющий текст.
Результат Перехода - основанный на заданных условиях - дальнейший путь Процесса, т.е. к какой Активности должна перейти процессная заявка.
Давайте рассмотрим пример:
$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', }, }, }, };
Содержит все условия, необходимые для осуществления этого Transition/Перехода. Пример:
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', }, }, }, },
Давайте рассмотрим подробно конфигурирование Условий.
Задает операторы для соединения элементов Условия. Возможные значения:
"and": Умалчиваемое значение. Все условия должны быть верны для выполнения Перехода.
"or"/"или": хотябы одно из условий должно быть верно.
"xor": должно быть верным не более одного условия.
Это имя одного из условий примера. Имя выбирается произвольно. Условия вычисляются в порядке очередности.
Задает способ, которым отдельные поля, проверяющие это условие, соединены друг с другом. Возможные значения:
'and': по умолчанию. Все проверяемые поля должны удовлетворять условию, чтобы результат был - "верно".
'or': хотя бы одно из полей должно удовлетворять условию.
'xor': не более одного поля должно соответствовать условию.
Указывает отдельные поля, значения которых должны быть проверены. В нашем примере:
Fields => { StateID => { Type => 'String', Match => '1', },
Пример имени поля. Следующие имена полей заявки могут использоваться:
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 поля из базы данных, для других поле (таких как SLA), используется его текущее значение.
Определяет тип проверяемого поля. Возможные значения:
'String/Строка': Сравнивает значение поля со строкой заданной в 'Match'. Верно, если их значения полностью совпадают.
'Hash': Сравнивает значение поля (hash) со значением hash заданным в 'Match'. Все значения должны совпадать.
'Array/Список': Сравнивает значение поля (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.
Использование UserID внутри параметра "Config" для Действия Перехода премлема для всех Действий Перехода (начиная с OTRS 3.2.4), в этом примереэто может быть в частности важным, если пользователь, выполняющий Переход, не имеет прав для передачи заявки в очередь "Junk", тогда как пользователь с UserID = 123, может их иметь.
Для многократного использования модулей Действий Переходов, достаточно задать несколько Действий Переходов в ваших настройках. Пример:
$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". Действие Перехода, используемое для конкретного Перехода определяется в параметре "Path" настроек Процесса.
OTRS стандартно имеет в составе несколько Действий Перехода, которые могут быть использованы в ваших процессах. Здесь вы можете найти их описание и способ настройки.
Задает одно или несколько динамических полей в процессной заявке. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set DynamicField Master to Master and Approved to 1', Module => 'Kernel::System::ProcessManagement::TransitionAction::DynamicFieldSet', Config => { MasterSlave => 'Master', Approved => '1', }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
'Главный/Подчиненный' и 'Утверждение' даны как пример имен динамических полей. Значения полей ("Главный" и "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|... # excluding any email type SenderType => 'agent', # agent|system|customer ContentType => 'text/plain; charset=ISO-8859-15', # or optional Charset & MimeType Subject => 'some short description', # required Body => 'the message text', # required HistoryType => 'OwnerUpdate', # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|... HistoryComment => 'Some free text!', From => 'Some Agent <email@example.com>', # not required but useful To => 'Some Customer A <customer-a@example.com>', # not required but useful Cc => 'Some Customer B <customer-b@example.com>', # not required but useful ReplyTo => 'Some Customer B <customer-b@example.com>', # not required InReplyTo => '<asdasdasd.12@example.com>', # not required but useful References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful NoAgentNotify => 0, # if you don't want to send agent notifications AutoResponseType => 'auto reply', # auto reject|auto follow up|auto reply/new ticket|auto remove ForceNotificationToUserID => [ 1, 43, 56 ], # if you want to force somebody ExcludeNotificationToUserID => [ 43, 56 ], # if you want full exclude somebody from notfications, # will also be removed in To: line of article, # higher prio as ForceNotificationToUserID ExcludeMuteNotificationToUserID => [ 43, 56 ], # the same as ExcludeNotificationToUserID but only the # sending gets muted, agent will still shown in To: # line of article }, }, };
"Имя" задает имя настраиваемого Действия Перехода. Его можно выбрать произвольно, но желательно, чтобы оно отражало цель действия.
"Тип заметки/сообщения" задает тип создаваемой заметки. Возможные значения: phone, fax, sms, webrequest, note-internal, note-external and note-report.
Тип отправителя задает тип отправителя для заметки/сообщения. Возможные значения: агент, система, клиент.
"ContentType"/"Тип содержания" задает тип содержимого заметки/сообщения. Возможные значения: 'text/plain; charset=ISO-8859-15' или любой другая допустимая кодировка или mime тип.
Тема - задает заголовок сообщения/заметки. Обязательна.
"Тело" - задает содержимое сообщения/заметки. Указывать обязательно.
HistoryType - задает тип записи истории. Возможные значения: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove, ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.
"HistoryComment" описывает содержимое записи истории.
"От", "Кому", "Копия" и "Ответить" задает адреса электронной почты с учетом правил, указанных выше.
'InReplyTo' и 'References' получает идентификаторы/IDs сообщений.
"NoAgentNotify"/Не иформировать агента - если установлено в "1", уведомление агенту посылаться не будет.
"AutoResponseType"/"Тип автоответа" - может принимать следующие значения: auto follow up/автоотклик, auto reject/автоотказ, auto remove/автоудаление, auto reply/автоответ, auto reply/new ticket/автоответ-новая заявка.
'ForceNotificationToUserID', 'ExcludeNotificationToUserID', 'ExcludeMuteNotificationToUserID' может содержать список UserIDs, которые либо всегда оповешаются, не оповещаются, либо помечаются как оповещенные, но на самом деле им не отправлено уведомление по электронной почте.
Создает заявку с сообщением, новая заявка может быть связана с процессной заявкой. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Ticket Create', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketCreate', Config => { # ticket required: Title => 'Some Ticket Title', Queue => 'Raw', # or QueueID => 123, Lock => 'unlock', Priority => '3 normal', # or PriorityID => 2, State => 'new', # or StateID => 5, CustomerID => '123465', CustomerUser => 'customer@example.com', OwnerID => 'someuserlogin', # or OwnerID => 123, # ticket optional: TN => $TicketObject->TicketCreateNumber(), # optional Type => 'Incident', # or TypeID => 1, not required Service => 'Service A', # or ServiceID => 1, not required SLA => 'SLA A', # or SLAID => 1, not required ResponsibleID => 123, # not required ArchiveFlag => 'y', # (y|n) not required PendingTime => '2011-12-23 23:05:00', # optional (for pending states) PendingTimeDiff => 123 , # optional (for pending states) # article required: ArticleType => 'note-internal', # note-external|phone|fax|sms|... # excluding any email type SenderType => 'agent', # agent|system|customer ContentType => 'text/plain; charset=ISO-8859-15', # or optional Charset & MimeType Subject => 'some short description', # required Body => 'the message text', # required HistoryType => 'OwnerUpdate', # EmailCustomer|Move|AddNote|PriorityUpdate|WebRequestCustomer|... HistoryComment => 'Some free text!', # article optional: From => 'Some Agent <email@example.com>', # not required but useful To => 'Some Customer A <customer-a@example.com>', # not required but useful Cc => 'Some Customer B <customer-b@example.com>', # not required but useful ReplyTo => 'Some Customer B <customer-b@example.com>', # not required MessageID => '<asdasdasd.123@example.com>', # not required but useful InReplyTo => '<asdasdasd.12@example.com>', # not required but useful References => '<asdasdasd.1@example.com> <asdasdasd.12@example.com>', # not required but useful NoAgentNotify => 0, # if you don't want to send agent notifications AutoResponseType => 'auto reply' # auto reject|auto follow up|auto reply/new ticket|auto remove ForceNotificationToUserID => [ 1, 43, 56 ], # if you want to force somebody ExcludeNotificationToUserID => [ 43,56 ], # if you want full exclude somebody from notifications, # will also be removed in To: line of article, # higher prio as ForceNotificationToUserID ExcludeMuteNotificationToUserID => [ 43,56 ], # the same as ExcludeNotificationToUserID but only the # sending gets muted, agent will still shown in To: # line of article TimeUnit => 123 # other: DynamicField_NameX => $Value, LinkAs => $LinkType, # Normal, Parent, Child, etc. (respective original ticket) UserID => 123, # optional, to override the UserID from the logged user }
"Имя" задает имя настраиваемого Действия Перехода. Его можно выбрать произвольно, но желательно, чтобы оно отражало цель действия.
'Название' Название заявки.
'Queue' или 'QueueID' задает имя или идентификатор очереди для использования в новой заявке.
'Lock' или 'LockID' задает статус блокировки для заявки.
'Priority' или 'PriorityID' задает приоритет или его идентификатор, если они будут использоваться в новой заявке.
'State' или 'StateID' задает состояние или его идентификатор для использования в новой заявке.
'CustomerID', идентификатор клиента/компании клиента для указания в новой заявке.
'CustomerUser', имя входа/login клиента, назначаемый новой заявке.
'Owner' or 'OwnerID', specifies the login or id of the agent that will be the new ticket owner.
'TN', пользовательский номер новой заявки.
'Type' или 'TypeID' задает название или id типа заявки для использования в новой заявке.
Service' или 'ServiceID' задает название или id Сервиса для использования в новой заявке.
'SLA' or 'SLaID' задает название или id SLA для использования в новой заявке.
'ResponsibleID', ID агента, назначаемого ответственным за новую заявку.
'PendingTime/Время напоминания', предопределенная дата для Ticket Pending Times, если состояние заявки относится к типу состояния - отложить
'PendingTimeDiff', динамическая дата (разница, выражаемая в секундах от текущей даты/времени) для установки Ticket Pending Times, если состояние заявки относится к типу состояния - отложить
"Тип заметки/сообщения" задает тип создаваемой заметки. Возможные значения: phone, fax, sms, webrequest, note-internal, note-external and note-report.
Тип отправителя задает тип отправителя для заметки/сообщения. Возможные значения: агент, система, клиент.
"ContentType"/"Тип содержания" задает тип содержимого заметки/сообщения. Возможные значения: 'text/plain; charset=ISO-8859-15' или любой другая допустимая кодировка или mime тип.
Тема - задает заголовок сообщения/заметки. Обязательна.
"Тело" - задает содержимое сообщения/заметки. Указывать обязательно.
'HistoryType/Тип записи Истории' задает типы/названия записей истории заявки. Возможные значения: AddNote, ArchiveFlagUpdate, Bounce, CustomerUpdate, EmailAgent, EmailCustomer, EscalationResponseTimeNotifyBefore, EscalationResponseTimeStart, EscalationResponseTimeStop, EscalationSolutionTimeNotifyBefore, EscalationSolutionTimeStart, EscalationSolutionTimeStop, EscalationUpdateTimeNotifyBefore, EscalationUpdateTimeStart, EscalationUpdateTimeStop, FollowUp, Forward, Lock, LoopProtection, Merged, Misc, Move, NewTicket, OwnerUpdate, PhoneCallAgent, PhoneCallCustomer, PriorityUpdate, Remove, ResponsibleUpdate, SendAgentNotification, SendAnswer, SendAutoFollowUp, SendAutoReject, SendAutoReply, SendCustomerNotification, ServiceUpdate, SetPendingTime, SLAUpdate, StateUpdate, Subscribe, SystemRequest, TicketDynamicFieldUpdate, TicketLinkAdd, TicketLinkDelete, TimeAccounting, TypeUpdate, Unlock, Unsubscribe, WebRequestCustomer.
"HistoryComment" описывает содержимое записи истории.
"От", "Кому", "Копия" и "Ответить" задает адреса электронной почты с учетом правил, указанных выше.
'InReplyTo' и 'References' получает идентификаторы/IDs сообщений.
"NoAgentNotify"/Не иформировать агента - если установлено в "1", уведомление агенту посылаться не будет.
"AutoResponseType"/"Тип автоответа" - может принимать следующие значения: auto follow up/автоотклик, auto reject/автоотказ, auto remove/автоудаление, auto reply/автоответ, auto reply/new ticket/автоответ-новая заявка.
'ForceNotificationToUserID', 'ExcludeNotificationToUserID', 'ExcludeMuteNotificationToUserID' может содержать список UserIDs, которые либо всегда оповешаются, не оповещаются, либо помечаются как оповещенные, но на самом деле им не отправлено уведомление по электронной почте.
'TimeUnit/Единицы времени' - время, потраченное на текущее действие по заявке, выраженное секундах, минутах, часах, и т. д.
DynamicField_NameX' где DynamicField_ обязательный префикс и NameX имя Динамического поля заданного для новой заявки (только на уровне заявки, не сообщений/заметкок)
'LinkAs/Связать как' для определения отношения к оригинальной заявке, с точки зрения новой заявки, например, Normal/Обычная, Parent/Родитель, Child/Потомок и т. д.
Задает клиента процессной заявки. Пример:
$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', }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
Пусто или CustomerID, задающий Customer 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, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
'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, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Owner"/"Владелец" - задает логин нового владельца.
"OwnerID" задает внутренний ID нового владельца.
Перемещает заявку в указанную очередь. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Queue Move Raw', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet', Config => { Queue => 'Raw', # or # QueueID => '2', }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Queue" задает имя очереди для перемещения.
"QueueID" задает внутренний ID для очереди для перемещения.
Изменяет владельца процессной заявки. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Responsible Set root@localhost', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketResponsibleSet', Config => { Responsible => 'root@localhost', # or ResponsibleID => 1, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Responsible" задает логин нового ответственного.
"ResponsibleID" задает внутренний ID нового ответственного.
Назначает сервис процессной заявке. Заявка должна иметь клиента и сервис должен быть назначен этому клиенту. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MyService service', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketServiceSet', Config => { Service => 'MyService', # or ServiceID => 123, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Service" задает новый сервис для процессной заявки. Требуется задать полное имя сервиса (например, GrandFatherService::FatherService::SonService ).
"ServiceID" задает внутренний ID нового сервиса.
Задает SLA для процессной заявки. Заявке должен быть уже назначен сервис и SLA должен быть привязан к этому сервису. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set MySLA SLA', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketSLASet', Config => { SLA => 'MyService', # or SLAID => 123, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"SLA" задает новое соглашение об уровне сервиса для процессной заявки.
"SLAID" задает внутренний ID новогоSLA.
Изменяет состояние процессной заявки. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set State to open', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketStateSet', Config => { State => 'open', # or StateID => 4, PendingTimeDiff => 123, }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"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', }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Title" задает новую тему заявки.
Задает Тип процессной заявки. Пример:
$Self->{'Process::TransitionAction'} = { 'TA1' => { Name => 'Set Ticket Type to default', Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTypeSet', Config => { Type => 'default', # or # TypeID => '1', }, }, };
"Имя" задает имя конфигурируемого Действия Перехода.
"Type"/"Тип" - задает название типа заявки.
"TypeID" задает внутренний ID для типа заявки.
С помощью ACL, вы можете ограничить выбор значений в процессной заявке. Смотрите также ACL reference для обзора полного синтаксиса ACL для заявок.
ACL могут быть заданы только в
Kernel/Config.pm
. /Правильнее с помощью редактора ACL в
SysConfig/. Пример:
$Self->{TicketAcl}->{'001-ACL-ProcessProperties'} = { Properties => { Process => { ProcessEntityID => ['P1'], ActivityEntityID => ['A1'], ActivityDialogEntityID => ['AD1'], } }, Possible => { ActivityDialog => ['AD1', 'AD3'], }, PossibleNot => { ActivityDialog => ['AD3'], }, };
Имя правила ACL. Для более полной информации обратитесь к the ACL manual.
Эта секция предназначена для проверки может ли правило 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 normal', то все три правила ACL будут удовлетворяться.
Первое правило сокращает список Диалогов Активности с 'AD1', 'AD2', 'AD3', 'AD4', 'AD5', 'AD6', 'AD7' до 'AD1', 'AD2', 'AD3', 'AD6', 'AD7' и запрещает 'AD4' and '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'], }, };