[Решено] Заявки со сроком исполнения

[hcc]

Добрый день.
Возникла необходимость использовать заявки с определённым сроком на исполнение (выставляется при назначении ответственного).
Для этого решил использовать новое состояние "в работе", входящее в тип состояния "pending auto": кнопочки выставления даты уже есть, сама дата и оставшееся время отображается в самой заявке, + можно автоматически переключать по истечению срока в какое-нибудь состояние вида "просрочено" и помещать в отдельный блок дайджеста.
Вроде бы всё красиво, но на практике любое сообщение от агента в сторону клиента (например, уточнение деталей задания) сбрасывает счётчик. Отключение параметра Ticket::Frontend::AgentTicketCompose###StateDefault (Ticket -> Frontend::Agent::Ticket::ViewCompose) ставит на месте следующего состояния "-", но время всё равно сбивается (на умолчальное значение для pending time, сутки).
Замечу, что подобные настройки для Заметки (Note) не влияют на установленный срок.
Можно ли как-то вообще отключить влияние на состояние заявки при переписке с клиентом?

[hcc]

В моём случае решением является полное отключение изменения pending time при отправке сообщения клиенту. Это можно осуществить, закомментировав следующие строки в файле Kernel/Modules/AgentTicketCompose.pm

Код: Выделить всё

# set pending time
        #elsif ( $StateData{TypeName} =~ /^pending/i ) {
        #    $Self->{TicketObject}->TicketPendingTimeSet(
        #        UserID   => $Self->{UserID},
        #        TicketID => $Self->{TicketID},
        #        Year     => $GetParam{Year},
        #        Month    => $GetParam{Month},
        #        Day      => $GetParam{Day},
        #        Hour     => $GetParam{Hour},
        #        Minute   => $GetParam{Minute},
        #    );
        #}

В итоге, отправляя сообщение клиенту без изменения состояния, мы не сбиваем pending date (для этого следует обязательно деактивировать параметр Ticket::Frontend::AgentTicketCompose###StateDefault, см. заглавие темы ). И, в то же время, можем сменить состояние на другое, разрешенное в Ticket::Frontend::AgentTicketCompose###StateType

[alexus]

Это очень "кривое" (Вы уж простите) решение. Для контроля сроков надо использовать SLA.

[hcc]

О "кривости" не спорю.

Тем не менее, сейчас система работает следующим образом: в систему поступает заявка с указанным сроком исполнения, для неё назначается ответственный и выставляется крайний срок (используется состояние типа pending).

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

Да, это несколько "неестественно" для ОТРС из коробки. Но можно ли что-то подобное можно организовать через SLA? Или можно лучше?

[alexus]

Да, это несколько "неестественно" для ОТРС из коробки. Но можно ли что-то подобное можно организовать через SLA? Или можно лучше?

Вы просто не умеете его "готовить"
Контроль сроков исполнения, уведомления, отображения и т.д. можно сделать как основе параметров эскалации очередей, так и на основе эскалации SLA.

[hcc]

Вы просто не умеете его "готовить"

Я как бы и не претендую.

Контроль сроков исполнения, уведомления, отображения и т.д. можно сделать как основе параметров эскалации очередей, так и на основе эскалации SLA.

Эскалация как передача задания другому лицу меня не устраивает в принципе - есть чётко назначенное ответственное лицо и есть чётко обозначенный срок выполнения задания. То есть, мне нужна организация работы именно в том виде, как я описал выше.
Врочем, что касается ОТРС - в теории многое выглядит просто и незатейливо. Но лишь до тех пор, пока не приходится столкнуться с этим на практике.

[alexus]

Эскалация в OTRS - это некоторое событие, которое может быть обработано любым способом под ваши задачи.