Поля "Дата ожидания" и "Затраченное время" "Тип заметки"

[Antony]

Абсолютно во всех формах, связанных с изменением заявки наблюдаю эти поля. Как их отключить? Где установки значений по умолчанию для этих полей?

У меня все заметки внешние, ну хотя б по умолчанию должны быть внешние. Затраченное время не интересует. Дата ожидания для всего 24 часа. Камасутру прочитал - не помогло.

[ykolesnikov]

Например:
Редактировать настройки конфигурации in Ticket -> Frontend::Agent::Ticket::ViewNote -->Ticket::Frontend::AgentTicketNote###ArticleTypeDefault
Дата ожидания у Вас неактивна и становится таковой только, если выбрано одно из следующих состояний с ожиданием. ЕЕ не отключить в настройках, если только править в коде.

Затраченное время: Редактировать настройки конфигурации in Ticket -> Frontend::Agent-->Ticket::Frontend::AccountTime. Если эту опцию выключить, то поле пропадет на всех формах.

[tester]

Я у себя отключал поля через файлы .dtl. Создал свою тему с корректированными файлами dtl, где просто за комментировал ненужные мне поля и сделал вид который радует глаз.
Результат лишние поля скрыты и не мешают глазу).
Однако многие поля нельзя так скрывать т.к. логика работы будет нарушена.

[ykolesnikov]

Именно так. Это как раз касается поля Дата ожидания. Чекбокс перед нею выводится, если установлено следующее состояние с ожиданием, иначе поле неактивно. Но просто закомментировать его в .dtl непросто, т.к. это обвязано логикой и, возможно не только в .dtl. Остальное можно в лоб - поля типа Критичность (Criticality) и Влияние (Impact), которые выводятся, если установлен ITSM. Но если сервисы не используются, то их значения не нужны, а в форме они присутствуют.

[Antony]

Критичность и влияние отключил через админку.
Поле с календарем ожидания активно для всех доступных статусов, которые я не трогал
Закрыт успешно
Закрыт неуспешно
Ожидает автозакрытия+
Ожидает автозакрытия-
Закрыто с обходным решением.

Логика ожидания пока мне не понятна. Поставил статус Ожидает автозакрытия+ с ожиданием сутки. Исправно считало сколько осталось до истечения срока. Потом пошло на увеличение со знаком минус и красным цветом, статус не изменился.

[ykolesnikov]

Надо включить в cron задание Pending_jobs
http://otrs.github.io/doc/manual/admin/ ... l#cronjobs
pending_jobs -Checks system for pending tickets, and closes them or sends reminders if needed.

[Antony]

Тип заметки и затраченное время убрал. После месяца тыкания в русскую версию ОТРС мне всё чаще начинает казаться, что на англ.яз мне б проще пошло.

поле Дата ожидания пока еще на месте. Закомментировать это поле в pm файлах для каждого окошка - уж очень топорно.
Закрываю заявки, которые ожидают Планировщиком.
Про cronjobs только узнал, спасибо.

[Antony]

По итогу с помощью cronjobs закрываются заявки, которые находятся в статусах, где это разрешено. В остальных статусах тыканье календаря ведет только к напоминанию агенту, что его дата ожидания наступила без каких-либо действий и приостановок эскалации.

[ykolesnikov]

Так и задумано. Напоминание напоминанием, а время эскалации тикает, почему оно должно останавливаться? Заявку не отменяли ведь.

[Antony]

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

1. Заявка Ожидает Автозакрытия сутки потом переводится в Закрыто успешно, который доступен только клиентам, автоматом и возврата из этого статуса не будет. Когда рассматривалась возможность установки агентом статуса Закрыто успешно самостоятельно с уведомлением клиенту, что если всё окей не отвечать на письмо, а если ответил - заявка сразу становилась Открытой - оказалось, что открытой она становится но счётчик времени больше не работает. Так работает возврат с любым статусом который имеет ТИП Закрытый.
2.Статусы, которые имеют ТИП статуса Удалённый при открытии заявки клиентом продолжают считать время выполнения. Но клиент может в любой момент без ограничений открыть заявку. Для примера: сегодня не работает 1с, глюкнул сервер лицензий. Клиент написал заявку, которую в течении часа разрулили и закрыли. Спустя неделю отвалился канал связи, а клиент возвращает заявку в работу - у него снова не работает 1С. Итог: Заявка сразу в просрочке, причём реально не по делу, а из-за незнания клиентом нюансов, которых он знать и не должен.

[ykolesnikov]

По первому вопросу не могу сказать, мы используем эскалации только для информирования агентов, поэтому, глубоко не копал. Хотя, считаю схему закрытия заявок только агентом - правильной, иначе, за клиентом набегаешься, а у него нет мотивации этим заниматься, он свое получил.
Что касается второго вопроса, то Если она удаленная,т.е. ненужная/ошибочная, то ее надо удалять из системы. По-моему, есть скрипт, который можно вставить в cron и он будет удалять такие заявки.

[Antony]

У меня задача была поставлена принципиально: сделать так чтоб агент не мог окончательно закрыть заявку. Или скриптом после Ожидает автозакрытия, или клиентом в веб-интерфейсе/почтовым письмом. Единственным окончательным закрытием заявки агентом является Отказ в обслуживании он же Закрыт неуспешно.

Что касается Удаленный, то этот ТИП СТАТУСА я не использую вообще. И удалять ничего нельзя - рукописи не горят)

[Antony]

С эскалацией тоже всё серъёзно.
На каждый Сервис или группу сервисов действует SLA. Каталог сервисов и SLA подписаны генеральным директором и не скажу, что это было просто осуществить. Таким образом попадание заявки в Эскалированные - это нарушение SLA = нарушение договоренностей между департаментом ИТ и бизнесом... Виновных надо знать в лицо. Ежемесячные антирейтинги с последующим клизмованием присутсвют. И уже не далеко не один человек и начальник отдела был отправлен писать заявление из-за просрочек.

П.С Заявок 6000-8000 в мес, агентов ~50 чел, 7 отделов. Первая линия 6 чел поочереди 24/7.
+2 конторы подрядчика + 4 чел аутсорсера
Благодаря такой жесткой политике процент просрочек с 12% упал до 4%

[ykolesnikov]

Используйте предупреждение перед эскалацией. Для очереди или SLA можно установить % времени до эскалации, при достижении которого выдается оповещение.