Страница 1 из 2

доработка AgentTicketPriority

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

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

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

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

Изображение

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

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

Изображение

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

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

Добавлено: 02 мар 2015, 15:51
sergeyprog
Вам надо что-то вроде такого сокращенного варианта? Или я совсем не понял что вам нужно?

ИзображениеИзображение

Re: доработка AgentTicketPriority

Добавлено: 02 мар 2015, 16:16
Antony
sergeyprog
совсем не поняли

Re: доработка AgentTicketPriority

Добавлено: 02 мар 2015, 21:27
alexus
Antony писал(а):Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA

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

Re: доработка AgentTicketPriority

Добавлено: 03 мар 2015, 10:35
Antony
в AgentTicketPhone как раз всё работает как надо.
В AgentTicketPriority надо так, как в AgentTicketPhone

Re: доработка AgentTicketPriority

Добавлено: 04 мар 2015, 17:44
Antony
Сведу вопрос к минимуму:

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

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

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

Re: доработка AgentTicketPriority

Добавлено: 05 мар 2015, 11:41
Antony
Как сделать поле очередь обязательным понятно стало из этой темы viewtopic.php?f=4&t=271

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

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

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

Re: доработка AgentTicketPriority

Добавлено: 05 мар 2015, 15:46
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 );

Re: доработка AgentTicketPriority

Добавлено: 05 мар 2015, 15:49
Antony
Тема начинает напоминать мой дневник.

Re: доработка AgentTicketPriority

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

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

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

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

Добавлено: 06 мар 2015, 16:28
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.

Re: доработка AgentTicketPriority

Добавлено: 06 мар 2015, 16:34
Antony
Речь зашла о как раз приоретизации и категоризации поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" первой линией.
Получилось криво. Казнить нельзя помиловать. Перфразирую:

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

Re: доработка AgentTicketPriority

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

:mrgreen:

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

Re: доработка AgentTicketPriority

Добавлено: 06 мар 2015, 17:00
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' и посмотреть что будет .)

Re: доработка AgentTicketPriority

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

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

Re: доработка AgentTicketPriority

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

Re: доработка AgentTicketPriority

Добавлено: 10 мар 2015, 15:11
Antony
надо не Dest добавить а NewQueueID
Добавил. Поведение такое же, как когда добавлял Dest:

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

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


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

Re: доработка AgentTicketPriority

Добавлено: 10 мар 2015, 21:02
alexus
Пошла вторая неделя... Прогресс уже намечается :).

Re: доработка AgentTicketPriority

Добавлено: 11 мар 2015, 13:26
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 похожего не нашел