доработка AgentTicketPriority

[Antony]

Даже не знаю с чего начать... Наверное, с описания процесса, чтоб обозначить необходимость этой доработки...

Ладно, начну с вопросов:
1.Реально ли сделать
2.Сколько это стоит
3.Сколько по-времени займет

Описание процесса (кратко): департамент ит. Заявки через сайт или почтовыми письмами поступают в очередь первой линии ДЛЯ ОБРАБОТКИ и назначения на соответствующую очередь. Также возможно оформление заявки оператором вручную через форму Новая телефонная заявка AgentTicketPhone.
Сервисы прописаны. SLA к ним прикручены. Типы заявок указаны: Инцидент, Обслуживание, Разработка, Заказ оборудования. В ОТРС сервисы привязаны к клиентам и по умолчанию всем клиентам (сотрудникам компании) доступны все сервисы
С помощью ACL настроено, что выбрав ТИП заявки - сужается круг для выбора ОЧЕРЕДИ; Выбор ОЧЕРЕДИ сужает круг для выбора СЕРВИСА. Связи СЕРВИСА и SLA работают и так хорошо.

При создании телефонной заявки AgentTicketPhone всё работает шикарно:



Оператор выбирает ТИП (Инцидент, обслуживание, разработка, заказ оборудования)
Выбирает ОЧЕРЕДЬ - отдел в компетенцию которого входит решение данной заявки
Вводит имя клиента (подтянуто из АД) - становятся доступны СЕРВИСЫ, которые доступны клиенту согласно выбранного ТИПА и ОЧЕРЕДИ.
Выбирает SLA которое соответсвует данному СЕРВИСУ.....
...потом суть заявки. И здесь все отлично.

Проблемы возникли на моменте обработки заявок, затянутых из почты или созданных клиентом через веб-интерфейс.
Клиент, при создании заявки может только указать тему и суть проблемы. Очереди и сервисы для выбора не доступны, ибо это не имеет смысла - правильности выбора там не будет уже проверено на личном опыте этих выборов.
Для редактирования этих заявок с целью указания ТИПА, ОЧЕРЕДИ, СЕРВИСА я решил использовать меню ИЗМЕНЕНИЯ ПРИОРИТЕТА AgentTicketPriority в открытой заявке AgentTicketZoom. Но тут логика работы обозначенных полей (а конкретно поля ОЧЕРЕДЬ) не такая как мне надо, что сеет хаос в это действие и без того загруженных операторов и выглядит абсолютно некрасиво для руководства департамента



Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA

Выбор очереди обязательным

[ykolesnikov]

Загляните в настройки Frontend::Agent::Ticket::ViewNote или Frontend::Agent::Ticket::ViewFreeText
По моему там есть все, что Вам нужно. Если еще надо сделать ограничения для каких-либо агентов, либо при выборе атрибутов можно еще добавить ACL именно для этого действия. Поле для творчества безгранично.

[sergeyprog]

Вам надо что-то вроде такого сокращенного варианта? Или я совсем не понял что вам нужно?

[Antony]

sergeyprog
совсем не поняли

[alexus]

Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA

Выбор очереди обязательным

В AgentTicketZoom или в AgentTicketPhone?
Вобщем, Вы хотите сразу совместить катгоризацию, приоритезацию и маршрутизацию? Немного странная задача с точки зрения логики процесса, но в принципе работы на пару часов, примерно. Пишите в личку контакты для связи.

[Antony]

в AgentTicketPhone как раз всё работает как надо.
В AgentTicketPriority надо так, как в AgentTicketPhone

[Antony]

Сведу вопрос к минимуму:

Как сделать так, чтоб поле ОЧЕРЕДЬ в AgentTicketPriority было обязательным и обновлялось при смене ТИПА также, как и в AgentTicketPhone?

Пока сравнение мною AgentTicketPhone.pm с AgentTicketActionCommon.pm (именно на него ссылается AgentTicketPriority.pm) успеха не принесло. Перл тяжеловат для чтения...

Может я вообще что-то неправильно себе замышляю и есть более простой способ маршрутизации полученной заявки с дефолтовыми значениями и обновления для нее ТИПА, ОЧЕРЕДИ и СЕРВИСА?

[Antony]

Как сделать поле очередь обязательным понятно стало из этой темы viewtopic.php?f=4&t=271

Как сделать так, чтоб поле ОЧЕРЕДЬ обновлялось при смене изменении других полей, как при создании телефонной заявки, еще не ясно...

[Antony]

А может быть такое, что обновление поля ОЧЕРЕДЬ нужно ловить не в pm файлах, а в dtl?

[Antony]

Сравнение PM и DTL файлов НовойТелефоннойЗаявки с такими файлами страницы изменения приоритета выявили существенное отличие: существует переменная $Dest , которая участвует в процессе формирования поля ОЧЕРЕДЬ...

Кто-то знает что это за зверь?

[Antony]

Сообщение ykolesnikov » 02 мар 2015, 14:04

Загляните в настройки Frontend::Agent::Ticket::ViewNote или Frontend::Agent::Ticket::ViewNote
По моему там есть все, что Вам нужно. Если еще надо сделать ограничения для каких-либо агентов, либо при выборе атрибутов можно еще добавить ACL именно для этого действия. Поле для творчества безгранично.

ViewNote, ViewNote имеют те же самые настройки, что и Frontend::Agent::Ticket::ViewPriority. Все эти формы имеют за основу один модуль AgentTicketActionCommon.pm. В своих модулях имеют ссылку на него, например AgentTicketPriority:

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

package Kernel::Modules::AgentTicketPriority;

use strict;
use warnings;

use base qw( Kernel::Modules::AgentTicketActionCommon );

[Antony]

Тема начинает напоминать мой дневник.

[vxb]

тема абсолютно характерна для умирающего opensource community, в котором участников можно поделить на 2 категории:
1. те кто разбирается с личными проблемами и уходит
2. те кто постоянно присутствует, разбирается в системе довольно давно, но в силу различных причин ограничивается помощью в виде rtfm, иногда с указанием на конкретный раздел этого fm

поэтому и блог, и это для маленького community нормально, привыкайте

что касается по существу: я такой механизм не использую, у меня нет 3 версии под руками, в 4 другая система шаблонов
AgentTicketPriority.tt содержит в себе include другого шаблона AgentTicketActionCommon.tt
и логика работы насколько я понимаю исходя из просмотра шаблона как раз такая как нужна - при выборе полей, наполнение остальных меняется в зависимости от предыдущего выбора

я бы предложил развернуть на тестовой машине 4 версию и посмотреть насколько реализация в ней соответствует ожиданиям и возможно запланировать миграцию с 3.x.x на 4.х.х

[ykolesnikov]

Коллеги, не вводите себя в заблуждение.
Логики, при которой заполнение последующих полей зависит от предыдущих, с точки зрения содержательной части там нет, это скорее технология.
Такую логику можно построить с помощью ACL, т.е. ограничить выбор значений последующих полей в зависимости от содержания предыдущих, это да.
Отображение вообще полей на экране в зависимости от выбора в предыдущем поле - это уже кастом. Он неоднократно обсуждался на английском форуме и продолжает развиваться сейчас, уже третий год. Здесь на форуме подобная тема тоже обсуждалась, поищите, если нужно в HOWTOS.

[vxb]

ТС устраивает принцип вывода и зависимость данных между выбором в select'ах, реализованный в базовом OTRS в механизме принятия заявки по телефону
он лишь хочет чтобы в окне смены приоритета был аналогичный механизм, в 3.х.х с его слов это не так, в 4.х.х я предполагаю что это так (основываясь на беглом анализе пожеланий ТС, и просмотре кода шаблона), но безусловно могу ошибаться, поэтому предлагаю ТС, как понимающему в полном объёме свою собственную задачу - провести эксперимент на 4.х.х и поделиться его результатами с community

[alexus]

Мы общались с ТС по данной задаче. Озвучили трудозатраты на реализацию - 2 часа. ТС хочет сам разобраться, остальные спецы понимают, что бесплатно обучать элементарной разработке нет времени. Так что пока - да, дневник.
По сути задачи - вооб

и логика работы насколько я понимаю

И задачу Вы не правильно понимаете. Я понимаю и могу решить, но мои разработчики денег стоят. И эта задача одинаково решается и для 3.x и для 4.x
А вообще, по-хорошему, сама постановка задачи неправильная, некорреткная. По всем процессным логикам маршрутизация (перемещение в очередь) происходит всегда после приоритезации, категоризации и первичной диагностики. Так что ТС выдумал себе проблему на ровном месте и героически её преодолевает.
Сейчас ТС скажет - это так начальство решило ! Можно открыть книжку по ITIL и ткнуть носом начальство в workflow-процессов управления инцидентами или обращениями, и заняться чем-то более полезным

[Antony]

AgentTicketPriority.tt содержит в себе include другого шаблона AgentTicketActionCommon.tt

В этом вопросе в версии 3,3,8 всё также. Разница только в старом формате файлов dtl. Но ничто не мешает убрать этот include из AgentTicketPriority и впихнуть туда измененный AgentTicketActionCommon.

По всем процессным логикам маршрутизация (перемещение в очередь) происходит всегда после приоритезации, категоризации и первичной диагностики.

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


Тем временем я попутно занимался ОТРС4.0.6
Новая телефонная заявка тут без изменений и с помощью ACL всё работает корректно и так как я хочу:
Выбираем тип - остальные поля пересчитываются под возможные значения согласно acl, далее выбираем очередь ИЗ ДОСТУПНЫХ.. потом сервисы, только те, которые могут быть назначены в вышеуказанную очередь согласно типа заявки...
Например: Типы заявок ОБСЛУЖИВАЕНИЕ и ИНЦИДЕНТ могут быть доступны для одной и той же очереди, но СЕРВИСЫ можно будет выбрать только согласно ТИПУ.
Например2: Есть очереди, которые не имеют сервисов, которые ИНЦИДЕНТ. Эти очереди с помощью ACL вообще не видны при выборе типа ИНЦИДЕНТ.
ACL рулит. Всё красиво.




Форма изменения Prioryty отличается интерфейсно в лучшую сторону. Поле ОЧЕРЕДЬ уже находится на нужном месте. Но логика работы полей такая же как и в 3,3,8. ACL нормально не отрабатывают этот весь блок связей из-за того, что поле ОЧЕРЕДЬ не такое, как в создании телефонной заявки. И именно это я пытаюсь побороть. Я пытался найти кусок кода, на работающей нормально для меня форме, отвечающий за этот блок и вставить его в нужное место. И считаю, что с Жавой, или Делфи с этим я бы справился точно. Но Перл пока мне не покоряется ((( А бабла никто не даст, хотя и эта форма редактирования заявки является реально принципиальной для руководства. Остаётся один вопрос: психануть потратить свои ползарплаты на 2 часа разработчиков Алексуса или продолжать грызть кактус. Причем я ни в коем случае не считаю ценник завышеным. Просто с оплатой труда в моей стране что-то не в порядке сейчас...

Думаю, что точно воспользуюсь советом №1: Внедрять буду 4.

[Antony]

Речь зашла о как раз приоретизации и категоризации поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" первой линией.

Получилось криво. Казнить нельзя помиловать. Перфразирую:

Речь зашла о как раз приоретизации и категоризации ПЕРВОЙ ЛИНИЕЙ поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" .

[Antony]

Можно открыть книжку по ITIL и ткнуть носом начальство в workflow-процессов управления инцидентами

Эту тему проходили. Эффект еще хуже. Им начинает хотеться после беглого прочтения документации вообще сказочных вещей. Приведу пример из жизни: Начальство заметило матрицу формирования приоритета заявки и тоже захотело такое прикрутить. По ихнему видению оператор первой линии должен выбрать при маршрутизации/создании заявки
1. Критичность сервиса для ДАННОГО СУБЪЕКТА
2. Влияние случившегося НА БИЗНЕС
а автоматом по матрице формируется
3. Приоритет заявки



Браво. С того времени стараюсь умных книжек им не подсовывать. Не на ту почву...

[vxb]

Antony
AgentTicketPhone.tt

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

[% WRAPPER JSOnDocumentComplete %]
<script type="text/javascript">//<![CDATA[
    $('#TypeID').bind('change', function (Event) {
        Core.AJAX.FormUpdate($('#NewPhoneTicket'), 'AJAXUpdate', 'TypeID', ['Dest', 'NewUserID', 'NewResponsibleID', 'NextStateID', 'PriorityID', 'ServiceID', 'SLAID', 'SignKeyID', 'CryptKeyID', 'To', 'Cc', 'Bcc', 'StandardTemplateID' [% Data.DynamicFieldNamesStrg %]]);
    });
//]]></script>
[% END %]

AgentTicketActionCommon.tt

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

[% WRAPPER JSOnDocumentComplete %]
<script type="text/javascript">//<![CDATA[
$('#TypeID').bind('change', function (Event) {
    Core.AJAX.FormUpdate($('#Compose'), 'AJAXUpdate', 'TypeID', [ 'ServiceID', 'SLAID', 'NewOwnerID', 'OldOwnerID', 'NewResponsibleID', 'NewStateID', 'NewPriorityID' [% Data.DynamicFieldNamesStrg %] ]);
});
//]]></script>
[% END %]

это обработчики которые висят на смене Типа заявки
в телефонной

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

Core.AJAX.FormUpdate($('#NewPhoneTicket'), 'AJAXUpdate', 'TypeID', ['Dest', 'NewUserID', 'NewResponsibleID', 'NextStateID', 'PriorityID', 'ServiceID', 'SLAID', 'SignKeyID', 'CryptKeyID', 'To', 'Cc', 'Bcc', 'StandardTemplateID' [% Data.DynamicFieldNamesStrg %]]);

в приоритете

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

Core.AJAX.FormUpdate($('#Compose'), 'AJAXUpdate', 'TypeID', [ 'ServiceID', 'SLAID', 'NewOwnerID', 'OldOwnerID', 'NewResponsibleID', 'NewStateID', 'NewPriorityID' [% Data.DynamicFieldNamesStrg %] ]);

Dest - как раз то что в телефонной заявке отвечает за выбор очереди, в приоритете NewQueueID, могу предложить попробовать перечислить в массиве, передающемся в качестве третьего элемента в Core.AJAX.FormUpdate 'NewQueueID' и посмотреть что будет .)

[Antony]

Dest - как раз то что в телефонной заявке отвечает за выбор очереди, в приоритете NewQueueID, могу предложить попробовать перечислить в массиве, передающемся в качестве третьего элемента в Core.AJAX.FormUpdate 'NewQueueID' и посмотреть что будет .)

Dest нашел вчера, писал в дневнике)) Добавил в массив. Получилось так, что колёсико обновлялки возле поля ОЧЕРЕДЬ крутится, но фактически содержание элементов не меняется. Теперь пытаюсь найти связь в одноименных файлах .pm - то с чего я начинал.

Чувствую, что близко....

[vxb]

надо не Dest добавить а NewQueueID
в форме приоритета - не dest, а newqueueid отвечает за id очереди...
это если ограничиваться правками шаблонов

[Antony]

надо не Dest добавить а NewQueueID

Добавил. Поведение такое же, как когда добавлял Dest:

при смене типа заявки колёсико обновлений крутится и возле ОЧЕРЕДИ, но на содержание не влияет.

так как я вставил NewQueueID в массив Core.AJAX.FormUpdate($('#Compose'), 'AJAXUpdate', 'TypeID' - колесико обновление поля очереди крутится только при изменении Типа заявки, а при изменении всех остальных полей остаётся статичным.


Самое примечательное, что при изменении Очереди - Сервисы подтягиваются согласно ACL. Только этого мне мало

[alexus]

Пошла вторая неделя... Прогресс уже намечается .

[Antony]

Думаю еще чего-то не хватает ACL
Например в AgentTicketPhone.pm есть такое

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

  # html output
        my $Services = $Self->_GetServices(
            %GetParam,
            %ACLCompatGetParam,
            %SplitTicketParam,
            CustomerUserID => $CustomerData{UserLogin} || '',
            QueueID        => $Self->{QueueID}         || 1,
        );
        my $SLAs = $Self->_GetSLAs(
            %GetParam,
            %ACLCompatGetParam,
            %SplitTicketParam,
            CustomerUserID => $CustomerData{UserLogin} || '',
            QueueID        => $Self->{QueueID}         || 1,
            Services       => $Services,
        );
        $Output .= $Self->_MaskPhoneNew(
            QueueID    => $Self->{QueueID},
            NextStates => $Self->_GetNextStates(
                %GetParam,
                %ACLCompatGetParam,
                %SplitTicketParam,
                CustomerUserID => $CustomerData{UserLogin} || '',
                QueueID        => $Self->{QueueID}         || 1,
            ),
            Priorities => $Self->_GetPriorities(
                %GetParam,
                %ACLCompatGetParam,
                %SplitTicketParam,
                CustomerUserID => $CustomerData{UserLogin} || '',
                QueueID        => $Self->{QueueID}         || 1,
            ),
            Types => $Self->_GetTypes(
                %GetParam,
                %ACLCompatGetParam,
                %SplitTicketParam,
                CustomerUserID => $CustomerData{UserLogin} || '',
                QueueID        => $Self->{QueueID}         || 1,
            ),
            Services          => $Services,
            SLAs              => $SLAs,
            StandardTemplates => $Self->_GetStandardTemplates(
                %GetParam,
                %ACLCompatGetParam,
                %SplitTicketParam,
                QueueID => $Self->{QueueID} || '',
            ),
            Users => $Self->_GetUsers(
                %GetParam,
                %ACLCompatGetParam,
                QueueID => $Self->{QueueID},
                %SplitTicketParam,
            ),
            ResponsibleUsers => $Self->_GetResponsibles(
                %GetParam,
                %ACLCompatGetParam,
                QueueID => $Self->{QueueID},
                %SplitTicketParam,
            ),
            To => $Self->_GetTos(
                %GetParam,
                %ACLCompatGetParam,
                %SplitTicketParam,
                CustomerUserID => $CustomerData{UserLogin} || '',
                QueueID => $Self->{QueueID},
            ),
            From         => $Article{From},
            Subject      => $Subject,
            Body         => $Body,
            CustomerID   => $Article{CustomerID},
            CustomerUser => $Article{CustomerUserID},
            CustomerData => \%CustomerData,
            Attachments  => \@Attachments,
            LinkTicketID => $GetParam{LinkTicketID} || '',

            #            %GetParam,
            %SplitTicketParam,
            DynamicFieldHTML => \%DynamicFieldHTML,
            MultipleCustomer => \@MultipleCustomer,
        );
        $Output .= $Self->{LayoutObject}->Footer();
        return $Output;

В AgentTicketCommon.pm похожего не нашел