Страница 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. Приоритет заявки
Браво.
С того времени стараюсь умных книжек им не подсовывать. Не на ту почву...
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 похожего не нашел