В этой статье я покажу как реализован процесс в OTRS 6 по созданию и введению в работу нового сотрудника со стороны отдела ИТ.
Вот такую я нарисовал схему взаимодействия между сотрудниками отдела ИТ:
А вот так выглядит процесс в OTRS 6:
- Первое окно интерфейса (Активность «A_start»)
Начало процесса в интерфейсе OTRS выглядит так:
Для создания этого окна этого нам потребуется:
Активность «A-start» — это начало процесса. Инженер тех. поддержки передает заявку о создании нового пользователя в очередь системному администратору. Почему так: в нашей организации все заявки OTRS первоначально попадают в очередь «технической поддержки» к инженеру, а он в свою очередь уже распределяет их по другим очередям. По сути это окно, оболочка в котором отображается все взаимодействие с пользователем.
и уже к этой активности мы назначаем:
Диалог активности «Начать создание пользователя» — Это уже «начинка» активности, в диалоге активности уже можно отображать поля, в которых возможно делать какой то выбор, например ставить чекбоксы (как в нашем случае), или выбирать из выпадающего списка значение (далее, в другом диалоге активности я это использую и т.д.)
Как видно в этой активности используется созданное мной ранее динамическое поле «newUserStart»
которое уже по умолчанию имеет отмеченный чекбокс
В процессе у него установлено «заполнение обязательно»,
т.е. если мы снимем чекбокс, то дальше этой активности процесс не пойдет, так как после этого диалога активности мы используем проверку на то — отмечен ли чекбокс или нет.
Следующий этап переход к активности «A_создание нового пользователя в AD» эта активность (окно веб интерфейса по сути) становится доступна очереди «Системный администратор», после того как инженер нажал кнопку «в работу» в первой активности «A-start»
Как видно между активностями «A_start» и «A_создание нового пользователя в AD» используется переход «T_start». Что такое «переход«?
Это логический блок, в котором можно задавать условия при которых возможно перейти к следующей активности (в нашем случае проверить отмечен ли чекбокс у динамического поля «newUserStart» ), какое выбрано значение из выпадающего списка и т.д.
Вот как настроена проверка на то, отмечен ли чекбокс:
Если условие выполнено, то процесс идет дальше и если «переходу» назначены «действия перехода», то выполняются они. В моем случае переходу назначены два «действия перехода» в одном («TA_toAdminSetName«) происходит изменение владельца заявки по ID на конкретного системного администратора:
и во втором действии перехода происходит изменение очереди на очередь «системный администратор»:
2. Второе окно интерфейса , активность «A_Создание учетной записи AD»
В этом интерфейсе уже работает системный администратор.
Вот так выглядит в интерфейсе OTRS:
Назначение этого окна для системного администратора в напоминании о том какие поля при создании нового пользователя в Active Directory должны быть заполнены. Напоминание описано в поле «Не забыть заполнить в AD»
После того как он создаст новую запись — он выставляет значение выпадающего списка «создание учетной записи в AD» в значение «yes» и проверяет является ли новый сотрудник руководителем (у нас у всех руководителей должен быть настроен ярлык для работы с 1C и создана учетная запись в 1C , этим занимается уже программист по 1C и в этой активности мы задаем разветвление процесса в зависимости от выбранного значения выпадающего списка «Это начальник?»
Вот так это выглядит в настройках Процесса:
Активность «A_Создание учетной записи AD и назначенный ей диалог активности «Создать учетную запись в Active Directory»
Сам диалог активности «Создать учетную запись в Active Directory»:
В этом диалоге активности используются 3 динамических поля
- textAD — простое текстовое поле, где перечислены инструкции для напоминания системному администратору
2. ADcreateUser — выпадающий список, имеющий два значения «no» (по умолчанию) и «yes».
3. isBoss — выпадающий список, имеющий два значения «no» (по умолчанию) и «yes».
Итак: выбрали «yes» в выпадающем списке «Это начальник?» (динамическое поле «isBoss«)
У нас срабатывает вот это действие перехода «T_Yes_isBossSendMail»
Внутри него происходит проверка на то какие значения выбраны в динамических полях:
после этого мы попадем в активность «A_For1C«:
где используется диалог активности «Заполнить и отправить заявку в 1С«
В ней используются 3 текстовых динамических поля, в которые нужно записать данные, которые необходимы программисту 1С для создания учетной записи непосредственно в 1С. Настройки этих полей одинаковые, приведу пример только одного «adminFioFor1C«:
В интерфейсе агента это выглядит вот так:
После нажатия на кнопку «отправить» начинает работать переход «TA_createTicket_1C«
Этот переход проверяет, заполнено ли что то в полях
и если проверка прошла, то выполняется действие перехода «TA_createTicket_1C» , это действие создает заявку в очереди «Группа 1С» которая заведена в OTRS и которую мы используем для создания заявок для программиста 1С.
Но в OTRS есть проблема — нельзя (из коробки) передавать значение дианамических полей. Т.е. если мы заполнили, например, поле «ФИО» в предыдущей активности, то передать значение этого поля в заявку программисту 1С не получится.
Само действие перехода, которое создает заявку программисту 1С, выглядит так:
В результате создается заявка в группе 1С вот в таком виде:
Так как никаких данных нет, мы их добавляем в виде заметки к этой заявке, где указываем нужные данные для создания учетки в 1С. Это конечно не удобно, но пока так. Далее программист 1С создает учетку, закрывает свою заявку и мы получаем об этом уведомление.
В интерфейсе же агента, после создания заявки программисту 1С, происходит переход в активность «A_todo_admin_createUser_1С»:
В интерфейсе агента выглядит так:
Как мы видим у нас отображаются заполненные ранее динамические поля («ФИО», «должность», «логин»)
=================Отступление========================
Для того, чтобы значения динамических полей отображались в процессных заявках нужно их добавить в настройках системы вот здесь Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicField в значение «1»
И включить отображение динамического поля и как оно будет называться вот здесь:
Ticket::Frontend::AgentTicketZoom###ProcessWidgetDynamicFieldGroups
============================Конец отступления================
— отсюда удобно копировать данные для заметки в заявку программисту 1С. Отсюда нам доступен диалог активности «Добавить в группу 1С«
Для чего это нужно: чтобы не забыть добавить пользователя в определенную группу в AD. У нас, для работы пользователя в программе 1С, используется терминальный режим и для этого пользователь должен состоять в специальной группе в Active Directory.
Здесь используются 2 динамических поля
DynamicField_adminAddGrop1C — выпадающий список (вариант «да» и «нет»)
DynamicField_adminArtcle1C — тип «чекбокс»
Эти типы полей мы рассматривали выше, настройки приводить не буду.
В интерфейсе OTRS агента это выглядит так:
После нажатия на кнопку попадаем в переход «TA_go_TODO_ADMIN«, который проверяет, что выбрано значение «yes» и поставлена галочка в активности «A_todo_admin_createUser_1С«
После этого попадаем в активность «A_todo_admin» , где нам доступен диалог активности «Проверить выполнены ли действия» :
Вот таки поля у этого диалога в интерфейсе OTRS агента:
Вот так в настройках процесса:
Думаю здесь пояснения не нужны, по сути это напоминание сис. администратору о небходимости проверить выполнены ли действия перечисленные в динамических полях. Да, мы попали бы в эту активность «A_todo_admin» если бы в активности «A_Создание учетной записи AD» в ее диалоге активности «Создать учетную запись в Active Directory» в динамическом поле «DynamicField_isBoss» выбрали значение «no«:
Как только все поля заполнены мы переходим в переход «T_toSupport«
В этом переходе я сделал проверку на то что в выпадающих списках выбраны значения «yes», т.е. я не стал проверять заполнены ли поля где нужно указывать логин и временный пароль пользователя, я просто сделал их обязательными к заполнению (на что указывает * в интерфейсе агента у этого поля)
вот так делается обязательность заполнения поля:
а вот настройки перехода «T_toSupport» :
После того как проверка прошла, выполняются 2 действия перехода:
Действие перехода «TA_toSupportSetName» изменяет владельца процессной заявки:
Действие перехода «TA_QueueToSupport» перемещает заявку в очередь «Группа поддержки»
Далее заявка попадает к инженеру тех. поддержки, в интерфейсе инженера она выглядит так:
Это окно активности «A_support» :
Нам доступен диалог активности «Выполняется на рабочем месте пользователя» , вот его настройки:
Вот так этот диалог выглядит в интерфейсе агента:
Инженер проверяет, выполняет работы перечисленные в этом интерфейсе, проставляет галочки напротив работ и передает в работу начальнику ИТ. Перед этим заявка проходит через переход «T_toChief» , где проверяется что все чекбоксы отмечены:
и если все ок, то отрабатывают два действия перехода, которые меняют владельца заявки и очередь заявки
Активность «A_chief»
Здесь интерес может представить поле «Проблема» с уже выбранным значением «Создание рабочего места». У нас при закрытии заявок в OTRS агент обязан указать к какой проблематике относилась заявка (имеется выпадающий список с перечнем известных проблем) за это отвечает динамическое поле «Programs», вот настройки динамического поля:
Вот так настроено это поле в процессной заявке:
После того как начальник проверил свой перечень работ, он нажимает кнопку «выполнено, закрыть заявку», заявка попадает в действие «Close Ticket»
где происходит проверка что галочки у полей проставлены:
и если это так, то выполняется действие перехода
которое меняет состояние заявки на закрыта успешно и назначает ответственного по заявке (кто закрыл заявку — в моем случае Начальник СИТ):
После этого процесс завершается, выполняется встроенная активность «Process complete»
Выгрузка процесса в формате yml:
