Управление Процессами

Введение
Пример процесса
Запись спроса
Утверждение менеджером
Обрабатывается отделом закупок
Обрабатывается почтовым отделом
Выполнение примера
Процесс (в качестве контейнера)
Диалоги Действий
Переходы
Действия Перехода
Деятельность
Схема процесса заказа книги
Эталонная последовательность настройки процесса
Процесс
Настройка Процесса
Название
CreateTime
CreateBy
ChangeTime
ChangeBy
State
StartActivity
StartActivityDialog
Путь
Активность
Настройка Активности
Название
CreateTime
CreateBy
ChangeTime
ChangeBy
ActivityDialog
ActivityDialog
Настройка ActivityDialog/Далога Активности
Название
CreateTime
CreateBy
ChangeTime
ChangeBy
Поля
Порядок полей
Текст подсказки для кнопки
Текст надписи на кнопке
Переход
Конфигурирование Перехода
Название
CreateTime
CreateBy
ChangeTime
ChangeBy
Условие
Действия Перехода
Настройка Действий Перехода
Название
Модуль
Config
Повторное использование модулей Действий Переходов.
Доступные Действия Перехода
Списки Контроля Доступа (ACLs)
Настройка ACL
001-ACL-ProcessProperties
Процесс
Possible/PossibleNot Activity Dialog/Диалог Активности

Введение

Эта функция в 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.

Создать следующие Очереди:

  • Управление

  • Сотрудники

  • Покупка

  • Почтовое отделение

Создает следующих Пользователей:

  • Менеджер

  • Сотрудник

Создать следующие Динамически Поля:

  • Название

    МеткаНазвание
    TypeText
    ОбъектЗаявк
  • Автор

    МеткаАвтор
    TypeText
    ОбъектЗаявк
  • ISBN

    МеткаISBN
    TypeText
    ОбъектЗаявк
  • Состояние

    МеткаСостояние
    TypeDropdown
    ОбъектЗаявк
    Возможные значения
    • Утверждение

    • Отказано в утверждении

    • Утвержденный

    • Заказ отменен

    • Заказ размещен

    • Посылка получена

    Примечание: Используйте именно эти возможные значения для "Ключ" и "Значение" при создании динамических полей.

  • Поставщик

    МеткаПоставщик
    TypeText
    ОбъектЗаявк
  • Цена

    МеткаЦена
    TypeText
    ОбъектЗаявк
  • DeliveryDate

    МеткаДата доставки
    TypeDate
    ОбъектЗаявк
  • DateOfReceipt

    МеткаДата получения
    TypeDate
    ОбъектЗаявк

Устанавливает следующие параметры SysConfig:

  • 'Ticket::Responsible': Yes

  • 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups':

    Ключ:Содержание:
    КнигаНазвание, Автор, ISBN
    ОбщийСостояние
    ЗаказЦена, Поставщик, Дада доставки
    ОтгрузкаDateOfReceipt
  • 'Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField':

    Ключ:Содержание:
    Автор1
    DateOfReceipt1
    DeliveryDate1
    ISBN1
    Цена1
    Состояние1
    Поставщик1
    Название1

Теперь давайте перейдем к описанию реального процесса. На следующем шаге мы определим конкретные объекты, которые нам необходимы.

Процесс (в качестве контейнера)

Для создания нового процесса необходимо перейти к пункту Управление процессами на панели Администратора, после нажатия на который мы попадем на экран Обзора процессов. После создания процесса мы получим возможность создания всех его объектов (всех составляющих процесса).

Note

Деятельности, Диалоги Активности, Переходы и Действия переходов определенные в одном процессе будут доступны для всех процессов системы.

Рисунок: Страница Администратора 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, чтобы узнать все обязательные и опциональные параметры.

Note

Начиная с 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',
                },
            },
        },
    }
};
                    

Название

Имя Процесса, оно может быть выбрано агентом при создании новой процессной заявки.

CreateTime

Время, когда процесс был создан.

CreateBy

UID пользователя, создавшего этот Процесс

ChangeTime

Время, когда процесс был изменен.

ChangeBy

UID пользователя, который вносил последние изменения в процесс.

State

Задает состояние процесса. Возможные значения:

  • 'Active' / Активный - все процессы, которые могут быть использованы в новых процессных заявках.

  • 'FadeAway' / Исчезающие - это процессы, которые нельзя выбрать более для новых заявок, но существующие заявки могут продолжать их использовать.

  • 'Inactive' / Неактивные - деактивированные процессы. Они не могут быть более использованы ни в новых, ни в существующих заявках.

StartActivity

При создании новой процессной заявки, StartActivity / Начальная Активность должна быть задана.Как только заявка будет создана, эта Активность будет инициирована и использована как начальная точка для первых проверок переходов.

StartActivityDialog

Для новой процессной заявки должен быть задан 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',
        },
    },
};
                

Название

Название активности.

CreateTime

Время создания.

CreateBy

UID пользователя, создавшего эту Активность.

ChangeTime

Время последнего изменения.

ChangeBy

UID пользователя, последним изменявшего эту Активность.

ActivityDialog

Раздел Диалог Активности содержит список Диалогов доступных для этой Активности. Все Диалоги текущей Активности отображаются в TicketZoom. Их порядок задается при настройке, в данном случае, 'AD5' отображается до 'AD6' и 'AD1'.

ActivityDialog

Диалог Активности это обычный экран и может быть использован в различных Активностях.

Настройка ActivityDialog/Далога Активности

Давайте рассмотрим пример конфигурации

$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',
    },
};
                    

Название

Имя Диалога Активности.

CreateTime

Время, когда он был создан.

CreateBy

UID пользователя, создавшего этот Диалог Активности.

ChangeTime

Время последнего изменения.

ChangeBy

UID пользователя, последним изменявшего этот Диалог Активности.

Поля

Содержит все поля, которые могут быть отображены в этом Диалоге Активности. Следующие поля могут быть использованы в данный момент:

    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',
            },
        },
    },
};
                    

Название

Имя Перехода

CreateTime

Время, когда он был создан.

CreateBy

UID пользователя, создавшего этот Переход

ChangeTime

Время последнего изменения.

ChangeBy

UID пользователя, последним изменявшего этот Переход.

Условие

Содержит все условия, необходимые для осуществления этого 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": должно быть верным не более одного условия.

Cond1

Это имя одного из условий примера. Имя выбирается произвольно. Условия вычисляются в порядке очередности.

Тип (Условия)

Задает способ, которым отдельные поля, проверяющие это условие, соединены друг с другом. Возможные значения:

  • 'and': по умолчанию. Все проверяемые поля должны удовлетворять условию, чтобы результат был - "верно".

  • 'or': хотя бы одно из полей должно удовлетворять условию.

  • 'xor': не более одного поля должно соответствовать условию.

Поля

Указывает отдельные поля, значения которых должны быть проверены. В нашем примере:

Fields => {
    StateID => {
        Type  => 'String',
        Match => '1',
    },
                        

StateID

Пример имени поля. Следующие имена полей заявки могут использоваться:

    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), используется его текущее значение.

Type

Определяет тип проверяемого поля. Возможные значения:

  • '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,
        },
    },
};
                    

Название

Имя Действия Перехода

Модуль

Задает используемый Perl модуль.

Config

Этот параметр содержит все настройки, требуемые для модуля. Их содержание зависит от конкретного используемого модуля Действия Перехода. Детали по конкрентным модулям смотрите в документации. В нашем примере, только Очередь должна быть задана. Тем не менее мы также передаем 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 стандартно имеет в составе несколько Действий Перехода, которые могут быть использованы в ваших процессах. Здесь вы можете найти их описание и способ настройки.

DynamicFieldSet

Задает одно или несколько динамических полей в процессной заявке. Пример:

$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") будут установлены этим Действием Перехода.

TicketArticleCreate

Создает сообщение/заметку и может быть использован для создания заметок или почтовых ответов. Пример:

$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, которые либо всегда оповешаются, не оповещаются, либо помечаются как оповещенные, но на самом деле им не отправлено уведомление по электронной почте.

TicketCreate

Создает заявку с сообщением, новая заявка может быть связана с процессной заявкой. Пример:

$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/Потомок и т. д.

TicketCustomerSet

Задает клиента процессной заявки. Пример:

$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 учетной записи - задает Имя клиента.

TicketLockSet

Устанавливает состояние блокирования процессной заявки. Пример:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set Lock to lock',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketLockSet',
        Config => {
            Lock   => 'lock',
            # or
            LockID => 2,
        },
    },
};
                        

"Имя" задает имя конфигурируемого Действия Перехода.

'Lock/Блокировка' - задает новый статус блокировки для процессной заявки.

'LockID' задает внутренний ID нового статуса блокировки.

TicketOwnerSet

Изменяет владельца этой процессной заявки. Пример:

$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 нового владельца.

TicketQueueSet

Перемещает заявку в указанную очередь. Пример:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Queue Move Raw',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketQueueSet',
        Config => {
            Queue => 'Raw',
            # or
            # QueueID => '2',
        },
    },
};
                        

"Имя" задает имя конфигурируемого Действия Перехода.

"Queue" задает имя очереди для перемещения.

"QueueID" задает внутренний ID для очереди для перемещения.

TicketResponsibleSet

Изменяет владельца процессной заявки. Пример:

$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 нового ответственного.

TicketServiceSet

Назначает сервис процессной заявке. Заявка должна иметь клиента и сервис должен быть назначен этому клиенту. Пример:

$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 нового сервиса.

TicketSLASet

Задает 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.

TicketStateSet

Изменяет состояние процессной заявки. Пример:

$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 час после заданного времени выполнения Действия Перехода).

TicketTitleSet

Задает Тему процессной заявки. Пример:

$Self->{'Process::TransitionAction'} = {
    'TA1' => {
        Name   => 'Set Ticket Title to Ticket-title',
        Module => 'Kernel::System::ProcessManagement::TransitionAction::TicketTitleSet',
        Config => {
            Title => 'Ticket-title',
        },
    },
};
                        

"Имя" задает имя конфигурируемого Действия Перехода.

"Title" задает новую тему заявки.

TicketTypeSet

Задает Тип процессной заявки. Пример:

$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 для типа заявки.

Списки Контроля Доступа (ACLs)

С помощью ACL, вы можете ограничить выбор значений в процессной заявке. Смотрите также ACL reference для обзора полного синтаксиса ACL для заявок.

Настройка 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'],
    },
};
                    

001-ACL-ProcessProperties

Имя правила ACL. Для более полной информации обратитесь к the ACL manual.

Процесс

Эта секция предназначена для проверки может ли правило ACL быть применено. Если параметр имеет заданное значение, правило применяется. Могут быть использованы следующие значения:

ProcessEntityID

ID процесса для текущего процесса. Совпадает, если заявка назначена этому процессу.

ActivityEntityID

ID Активности, которой назначена процессная заявка в текущий момент.

ActivityDialogEntityID

ID Диалога Активности открытого в настоящий момент для процессной заявки.

Possible/PossibleNot Activity Dialog/Диалог Активности

Здесь вы можете задать список 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'],
    },
};