OTRS позволяет изменять предопределенные состояния заявок и их типы, а также добавлять новые. Для состояния важны два атрибута: имя (state-name) и тип (state-type).
Предустановленные состояния в OTRS: "закрыто успешно", "закрыто неудачно", "обьеденено", "новая", "открытая", "в ожидании с автозакрытием+", "в ожидании с автозакрытием-", "в ожидании с напоминанием", "удаленная".
Заявки находятся в этом состоянии, когда они создаются на основе входящих сообщений электронной почты.
После того как время ожидания истекло, владелец заявки будет получать напоминание на электронную почту. Если заявка не закрыта, то напоминание о заявке будет отправлено всем агентам в очереди. Напоминание о заявках будет отправлено только в рабочее время и будет повторятся каждые 24-часа, пока агент не изменит состояние заявки. Время, которое заявка проведет с таким статусом будет добавлено к времени эскалации.
Если время ожидания вышло, заявки с этим статусом будут установлены в "Закрытые неуспешно". Время, проведенное заявкой в этом статусе будет добавлено к времени эскалации.
Если вышло время ожидания, заявки с этим статусом будут установлены в "Закрыто Успешно". Время, проведенное заявкой в этом статусе будет добавлено к времени эскалации.
Это конечное состояние для заявок, которые были решены успешно. В зависимости от конфигурации, у вас будет или не будет возможности заново открыть ранее закрытые заявки.
Каждое состояние имеет название (state-name) и тип (state-type). Чтобы создать новое состояние перейдите по ссылке Состояния на Панели Администрирования и нажмите кнопку "Добавить состояние". Можно свободно выбирать имя нового состояния. Типы состояний не могут изменятся посредством веб-интерфейса. Если нужно добавить новые типы или изменить существующие, - все изменения придется делать напрямую в базе данных. Предустановленные типы состояний не могут быть изменены, поскольку это может привести к непредсказуемым результатам. Например, расчет эскалации и фунция разблокирования основаны на конкретных типах состояний.
The name of an already existing state can be changed, or new states added
through this screen. If the state "new" has been changed via the web
interface, this change also has to be configured via the config file
Kernel/Config.pm
or via the SysConfig interface. The
settings specified in the script below have to be modified to ensure that
OTRS works with the changed state for "new".
[...] # PostmasterDefaultState # (The default state of new tickets.) [default: new] $Self->{PostmasterDefaultState} = 'new'; # CustomerDefaultState # (default state of new customer tickets) $Self->{CustomerDefaultState} = 'new'; [...]
Сценарий: Изменение параметров настройки в Kernel/Config.pm.
Если нужно добавить новый тип состояния, то это можно сделать с помощью клиентской программы управления базами данных, изменив таблицу ticket_state_type базы данных OTRS, как это показано в нижеприведенном сценарии
linux:~# mysql -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 23 to server version: 5.0.16-Debian_1-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> use otrs; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> insert into ticket_state_type (name,comments) values ('own','Own state type'); Query OK, 1 row affected (0.00 sec) mysql> quit Bye linux:~#
Script: Изменение базы данных OTRS.
На данный момент можно использовать новый тип состояния, который вы только что создали. Как только состояние будет связано с этим новым типом состояния, то чтобы убедится что новое состояние используется и работает коректно нужно также изменить настройки OTRS. Используя SysConfig внесите изменения в следующие опции:
Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateDefault - определить следующее состояние по умолчанию для новых заявок созданных на основе телефонного звонка.
Ticket -> Frontend::Agent::Ticket::ViewPhoneNew > AgentTicketPhone###StateType - для определения последующих доступных состояний для новых заявок, созданных на основе телефонного звонка.
Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateDefault - установка последующих следующих состояний для заявок созданных на базе сообщений электронной почты.
Ticket -> Frontend::Agent::Ticket::ViewEmailNew > AgentTicketEmail###StateType - для определения последующих доступных состояний для новых заявок созданных на базе сообщений электронной почты.
Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###State - для определения последующих доступных состояний для новых заявок созданных на базе новых телефонных статей.
Ticket -> Frontend::Agent::Ticket::ViewPhoneOutbound > AgentTicketPhoneOutbound###StateType - для определения последующих доступных состояний для новых заявок созданных на базе новых телефонных статей.
Ticket:Frontend::Agent::Ticket::ViewMove:Ticket::DefaultNextMoveStateType - для определения последующих доступных состояний для перемещенных заявок.
Ticket -> Frontend::Agent::Ticket::ViewBounce > StateDefault - для определения последующих доступных состояний для "подпрыгивающих" заявок.
Ticket -> Frontend::Agent::Ticket::ViewBounce > StateType - для определения последующих доступных состояний для экранов с отказами.
Ticket -> Frontend::Agent::Ticket::ViewBulk > StateDefault - для определения прдеопределенных последующих состояний для груповых действий.
Ticket -> Frontend::Agent::Ticket::ViewBulk > StateType - для определения прдеопределенных последующих состояний для экрана груповых действий
Ticket -> Frontend::Agent::Ticket::ViewClose > StateDefault - для определения прдеопределенных последующих состояний после закрытия заявки
Ticket -> Frontend::Agent::Ticket::ViewClose > StateType - для определения прдеопределенных последующих состояний для страницы закрытия.
Ticket -> Frontend::Agent::Ticket::ViewCompose > StateDefault - для определения прдеопределенных последующих состояний для Compose-страницы
Ticket -> Frontend::Agent::Ticket::ViewCompose > StateType - для определения прдеопределенных последующих состояний для Compose-страницы.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - для определения прдеопределенных последующих состояний после перенаправления заявки.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - для определения прдеопределенных последующих состояний для страници перенаправления.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateDefault - для определения прдеопределенных последующих состояний для страницы free-text.
Ticket -> Frontend::Agent::Ticket::ViewForward > StateType - для определения прдеопределенных последующих состояний для free text-страницы.
Ticket -> Core::PostMaster > PostmasterDefaultState - для определения прдеопределенных последующих состояний для заявок, созданых с сообщений электронной почты.
Ticket -> Core::PostMaster > PostmasterFollowUpState - для определения прдеопределенных последующих состояний для заявок после последующих, которые должны быть сохранены.
Ticket -> Core::PostMaster > PostmasterFollowUpStateClosed - для определения состояния заявок, после того как придет новый ответ на уже закрытую заявку.
Ticket -> Core::Ticket > ViewableStateType - для определения состояний, которые будут отображатся в различных местах системы, напримерв в Queueview.
Ticket -> Core::Ticket > UnlockStateType - для определения типов состояний для разблокированых заявок.
Ticket -> Core::Ticket > PendingReminderStateType - для определения типов состояний для заявок с напоминанием.
Ticket -> Core::Ticket > PendingAutoStateType - для определения типов состояний для ожидающих заявок.
Ticket -> Core::Ticket > StateAfterPending - для определения состояния заявки установленой в Таймере Авто-Ожидания, если время для настроенного состояния истекло.
OTRS поставляется с пятью предустановлеными уровнями приоритетов, которые можно изменить перейдя по ссылке "Приоритеты" на Панели Администрирования. При создании настраиваемого списка приоритетов, пожалуйста помните, что они сортируются в алфавитном порядке. Также OTRS сортирует заявки в QueueView по их внутреннему номеру (ID).
Как и в случае с другими сущностями OTRS, приоритеты не могут быть удалены, а только деактивированы путем установки параметра Действительный в значение не действительный или не действительный-временно.
Если был создан новый приоритет, или был изменен уже существующий, то можно также произвести изменения некоторых параметров в SysConfig:
Ticket:Core::Postmaster::PostmasterDefaultPriority - определяет предустановленный приоритет для всех входящих сообщений электронной почты.
Ticket:Frontend::Agent:Ticket::ViewPhoneNew:Priority - определяет предустановленный приоритет для новых Заявок созданных на основе Телефонных Звонков.
Ticket:Frontend::Agent:Ticket::ViewEmailNew:Priority - определяет предустановленый приоритет на странице с новыми Email-Заявками для агентов.
Ticket:Frontend::Customer:Ticket::ViewNew:PriorityDefault - определяет предустановленные приоритеты для страцицы Новые Заявки в пользовательском веб-интерфейсе.
From OTRS 2.1 on, it is possible to assign a person as being responsible for a ticket, in addition to its owner. Moreover, all activities connected with the ticket can be watched by someone other than the ticket owner. These two functionalities are implemented with the TicketResponsible and TicketWatcher features, and facilitate the assignment of tasks and working within hierarchical team structures.
Функция ответственности за заявку способствует ее полной обработки еагентом, который не является владельцем заявки. Таким образом агент, который заблокировал заявку может передать ее другому агенту, который не является владельцем заявки, для того, чтобы второй просто дал ответ на вопрос. После того как запрос был рассмотрен, первый агент может снять ответственность за заявку с второго агента.
С помощью параметров конфигурации Ticket::Responsible, можно активировать функцию ответственности за заявку. Это приведет к появлению на экране трех дополнительных иконок/значков.
Ответственность за заявку может быть назначена после открытия ее содержимого, нажав ссылку "Ответственность", соответсвующего меню в шаблоне просмотра подробной информации о заявке агентского веб-интерфейса (см. нижеприведенный сценарий).
Рисунок: Изменение Ответственного за заявку в шаблоне просмотра подробной инф. о заявке.
После нажатия на кнопку "Ответственность", откроется всплывающее окно для изменения ответственности этой заявки (см. нижеприведенный Рисунок). Этот шаблон/диалог также может быть использован для отправки сообщения новому агенту, который будет нести ответственность за эту заявку.
Рисунок: Всплывающий диалог для изменения ответственного за заявку.
Если активирована функция ответственности за заявку, то в шаблоне Ответственность, агентского веб-интерфейса OTRS можно просмотреть список всех заявок, за которые агент несет ответственность.
Начиная с OTRS 2.1 и выше с помощью функции TicketWatcher, выбранные агенты, такие как, например, руководители могут просматривать определенные заявки без их обработки.
Функция TicketWatcher может быть активирована с помощью параметра конфигурации Ticket::Watcher, после чего в панели инструментов появлятся новые ссылки. Используя Ticket::WatcherGroup можно определить одну или несколько групп пользователей с правами просмотра заявок.
Для того чтобы смотреть заявку, перейдите к шаблону просмотра подробной информации о заявке и нажмите ссылку "Подписатся" в меню заявки (см. нижеприведенный Рисунок).
Figure: Подписка на просмотр подробной информации о заявке.
Если вы больше не хотите просматривать определенную заявку, перейдите к шаблону просмотра подробной информации заявки и нажмите кнопку "Отменить подписку" в меню заявки (см. нижеприведенный рисунок).
Рисунок: Отказ от подписи на заявку в шаблоне просмотра подробной информации о заявке.
Как только активирована функция "просмотр заявок", то список всех просматриваемых заявок будет доступен в шаблоне Watched View (см. нижеприведенный Рисунок).
Рисунок: Шаблон для просматриваемых заявок.