доработка AgentTicketPriority
Модератор: ykolesnikov
доработка AgentTicketPriority
Даже не знаю с чего начать... Наверное, с описания процесса, чтоб обозначить необходимость этой доработки...
Ладно, начну с вопросов:
1.Реально ли сделать
2.Сколько это стоит
3.Сколько по-времени займет
Описание процесса (кратко): департамент ит. Заявки через сайт или почтовыми письмами поступают в очередь первой линии ДЛЯ ОБРАБОТКИ и назначения на соответствующую очередь. Также возможно оформление заявки оператором вручную через форму Новая телефонная заявка AgentTicketPhone.
Сервисы прописаны. SLA к ним прикручены. Типы заявок указаны: Инцидент, Обслуживание, Разработка, Заказ оборудования. В ОТРС сервисы привязаны к клиентам и по умолчанию всем клиентам (сотрудникам компании) доступны все сервисы
С помощью ACL настроено, что выбрав ТИП заявки - сужается круг для выбора ОЧЕРЕДИ; Выбор ОЧЕРЕДИ сужает круг для выбора СЕРВИСА. Связи СЕРВИСА и SLA работают и так хорошо.
При создании телефонной заявки AgentTicketPhone всё работает шикарно:
Оператор выбирает ТИП (Инцидент, обслуживание, разработка, заказ оборудования)
Выбирает ОЧЕРЕДЬ - отдел в компетенцию которого входит решение данной заявки
Вводит имя клиента (подтянуто из АД) - становятся доступны СЕРВИСЫ, которые доступны клиенту согласно выбранного ТИПА и ОЧЕРЕДИ.
Выбирает SLA которое соответсвует данному СЕРВИСУ.....
...потом суть заявки. И здесь все отлично.
Проблемы возникли на моменте обработки заявок, затянутых из почты или созданных клиентом через веб-интерфейс.
Клиент, при создании заявки может только указать тему и суть проблемы. Очереди и сервисы для выбора не доступны, ибо это не имеет смысла - правильности выбора там не будет уже проверено на личном опыте этих выборов.
Для редактирования этих заявок с целью указания ТИПА, ОЧЕРЕДИ, СЕРВИСА я решил использовать меню ИЗМЕНЕНИЯ ПРИОРИТЕТА AgentTicketPriority в открытой заявке AgentTicketZoom. Но тут логика работы обозначенных полей (а конкретно поля ОЧЕРЕДЬ) не такая как мне надо, что сеет хаос в это действие и без того загруженных операторов и выглядит абсолютно некрасиво для руководства департамента
Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA
Выбор очереди обязательным
Ладно, начну с вопросов:
1.Реально ли сделать
2.Сколько это стоит
3.Сколько по-времени займет
Описание процесса (кратко): департамент ит. Заявки через сайт или почтовыми письмами поступают в очередь первой линии ДЛЯ ОБРАБОТКИ и назначения на соответствующую очередь. Также возможно оформление заявки оператором вручную через форму Новая телефонная заявка AgentTicketPhone.
Сервисы прописаны. SLA к ним прикручены. Типы заявок указаны: Инцидент, Обслуживание, Разработка, Заказ оборудования. В ОТРС сервисы привязаны к клиентам и по умолчанию всем клиентам (сотрудникам компании) доступны все сервисы
С помощью ACL настроено, что выбрав ТИП заявки - сужается круг для выбора ОЧЕРЕДИ; Выбор ОЧЕРЕДИ сужает круг для выбора СЕРВИСА. Связи СЕРВИСА и SLA работают и так хорошо.
При создании телефонной заявки AgentTicketPhone всё работает шикарно:
Оператор выбирает ТИП (Инцидент, обслуживание, разработка, заказ оборудования)
Выбирает ОЧЕРЕДЬ - отдел в компетенцию которого входит решение данной заявки
Вводит имя клиента (подтянуто из АД) - становятся доступны СЕРВИСЫ, которые доступны клиенту согласно выбранного ТИПА и ОЧЕРЕДИ.
Выбирает SLA которое соответсвует данному СЕРВИСУ.....
...потом суть заявки. И здесь все отлично.
Проблемы возникли на моменте обработки заявок, затянутых из почты или созданных клиентом через веб-интерфейс.
Клиент, при создании заявки может только указать тему и суть проблемы. Очереди и сервисы для выбора не доступны, ибо это не имеет смысла - правильности выбора там не будет уже проверено на личном опыте этих выборов.
Для редактирования этих заявок с целью указания ТИПА, ОЧЕРЕДИ, СЕРВИСА я решил использовать меню ИЗМЕНЕНИЯ ПРИОРИТЕТА AgentTicketPriority в открытой заявке AgentTicketZoom. Но тут логика работы обозначенных полей (а конкретно поля ОЧЕРЕДЬ) не такая как мне надо, что сеет хаос в это действие и без того загруженных операторов и выглядит абсолютно некрасиво для руководства департамента
Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA
Выбор очереди обязательным
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: доработка AgentTicketPriority
Загляните в настройки Frontend::Agent::Ticket::ViewNote или Frontend::Agent::Ticket::ViewFreeText
По моему там есть все, что Вам нужно. Если еще надо сделать ограничения для каких-либо агентов, либо при выборе атрибутов можно еще добавить ACL именно для этого действия. Поле для творчества безгранично.
По моему там есть все, что Вам нужно. Если еще надо сделать ограничения для каких-либо агентов, либо при выборе атрибутов можно еще добавить ACL именно для этого действия. Поле для творчества безгранично.
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
-
- OTRS Новобранец
- Сообщения: 6
- Зарегистрирован: 12 фев 2015, 14:14
Re: доработка AgentTicketPriority
sergeyprog
совсем не поняли
совсем не поняли
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
-
- OTRS Гуру
- Сообщения: 5199
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: доработка AgentTicketPriority
В AgentTicketZoom или в AgentTicketPhone?Antony писал(а):Надо сделать чтоб было как в AgentTicketZoom или в идеале
Выбор ТИПА
Выбор ОЧЕРЕДИ
Выбор СЕРВИСА
Выбор SLA
Выбор очереди обязательным
Вобщем, Вы хотите сразу совместить катгоризацию, приоритезацию и маршрутизацию? Немного странная задача с точки зрения логики процесса, но в принципе работы на пару часов, примерно. Пишите в личку контакты для связи.
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: доработка AgentTicketPriority
в AgentTicketPhone как раз всё работает как надо.
В AgentTicketPriority надо так, как в AgentTicketPhone
В AgentTicketPriority надо так, как в AgentTicketPhone
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Сведу вопрос к минимуму:
Как сделать так, чтоб поле ОЧЕРЕДЬ в AgentTicketPriority было обязательным и обновлялось при смене ТИПА также, как и в AgentTicketPhone?
Пока сравнение мною AgentTicketPhone.pm с AgentTicketActionCommon.pm (именно на него ссылается AgentTicketPriority.pm) успеха не принесло. Перл тяжеловат для чтения...
Может я вообще что-то неправильно себе замышляю и есть более простой способ маршрутизации полученной заявки с дефолтовыми значениями и обновления для нее ТИПА, ОЧЕРЕДИ и СЕРВИСА?
Как сделать так, чтоб поле ОЧЕРЕДЬ в AgentTicketPriority было обязательным и обновлялось при смене ТИПА также, как и в AgentTicketPhone?
Пока сравнение мною AgentTicketPhone.pm с AgentTicketActionCommon.pm (именно на него ссылается AgentTicketPriority.pm) успеха не принесло. Перл тяжеловат для чтения...
Может я вообще что-то неправильно себе замышляю и есть более простой способ маршрутизации полученной заявки с дефолтовыми значениями и обновления для нее ТИПА, ОЧЕРЕДИ и СЕРВИСА?
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Как сделать поле очередь обязательным понятно стало из этой темы viewtopic.php?f=4&t=271
Как сделать так, чтоб поле ОЧЕРЕДЬ обновлялось при смене изменении других полей, как при создании телефонной заявки, еще не ясно...
Как сделать так, чтоб поле ОЧЕРЕДЬ обновлялось при смене изменении других полей, как при создании телефонной заявки, еще не ясно...
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
А может быть такое, что обновление поля ОЧЕРЕДЬ нужно ловить не в pm файлах, а в dtl?
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Сравнение PM и DTL файлов НовойТелефоннойЗаявки с такими файлами страницы изменения приоритета выявили существенное отличие: существует переменная $Dest , которая участвует в процессе формирования поля ОЧЕРЕДЬ...
Кто-то знает что это за зверь?
Кто-то знает что это за зверь?
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
ViewNote, ViewNote имеют те же самые настройки, что и Frontend::Agent::Ticket::ViewPriority. Все эти формы имеют за основу один модуль AgentTicketActionCommon.pm. В своих модулях имеют ссылку на него, например AgentTicketPriority:Сообщение ykolesnikov » 02 мар 2015, 14:04
Загляните в настройки Frontend::Agent::Ticket::ViewNote или Frontend::Agent::Ticket::ViewNote
По моему там есть все, что Вам нужно. Если еще надо сделать ограничения для каких-либо агентов, либо при выборе атрибутов можно еще добавить ACL именно для этого действия. Поле для творчества безгранично.
Код: Выделить всё
package Kernel::Modules::AgentTicketPriority;
use strict;
use warnings;
use base qw( Kernel::Modules::AgentTicketActionCommon );
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Тема начинает напоминать мой дневник.
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
тема абсолютно характерна для умирающего opensource community, в котором участников можно поделить на 2 категории:
1. те кто разбирается с личными проблемами и уходит
2. те кто постоянно присутствует, разбирается в системе довольно давно, но в силу различных причин ограничивается помощью в виде rtfm, иногда с указанием на конкретный раздел этого fm
поэтому и блог, и это для маленького community нормально, привыкайте
что касается по существу: я такой механизм не использую, у меня нет 3 версии под руками, в 4 другая система шаблонов
AgentTicketPriority.tt содержит в себе include другого шаблона AgentTicketActionCommon.tt
и логика работы насколько я понимаю исходя из просмотра шаблона как раз такая как нужна - при выборе полей, наполнение остальных меняется в зависимости от предыдущего выбора
я бы предложил развернуть на тестовой машине 4 версию и посмотреть насколько реализация в ней соответствует ожиданиям и возможно запланировать миграцию с 3.x.x на 4.х.х
1. те кто разбирается с личными проблемами и уходит
2. те кто постоянно присутствует, разбирается в системе довольно давно, но в силу различных причин ограничивается помощью в виде rtfm, иногда с указанием на конкретный раздел этого fm
поэтому и блог, и это для маленького community нормально, привыкайте
что касается по существу: я такой механизм не использую, у меня нет 3 версии под руками, в 4 другая система шаблонов
AgentTicketPriority.tt содержит в себе include другого шаблона AgentTicketActionCommon.tt
и логика работы насколько я понимаю исходя из просмотра шаблона как раз такая как нужна - при выборе полей, наполнение остальных меняется в зависимости от предыдущего выбора
я бы предложил развернуть на тестовой машине 4 версию и посмотреть насколько реализация в ней соответствует ожиданиям и возможно запланировать миграцию с 3.x.x на 4.х.х
debian 7 / postgresql / otrs 4.0.6
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: доработка AgentTicketPriority
Коллеги, не вводите себя в заблуждение.
Логики, при которой заполнение последующих полей зависит от предыдущих, с точки зрения содержательной части там нет, это скорее технология.
Такую логику можно построить с помощью ACL, т.е. ограничить выбор значений последующих полей в зависимости от содержания предыдущих, это да.
Отображение вообще полей на экране в зависимости от выбора в предыдущем поле - это уже кастом. Он неоднократно обсуждался на английском форуме и продолжает развиваться сейчас, уже третий год. Здесь на форуме подобная тема тоже обсуждалась, поищите, если нужно в HOWTOS.
Логики, при которой заполнение последующих полей зависит от предыдущих, с точки зрения содержательной части там нет, это скорее технология.
Такую логику можно построить с помощью ACL, т.е. ограничить выбор значений последующих полей в зависимости от содержания предыдущих, это да.
Отображение вообще полей на экране в зависимости от выбора в предыдущем поле - это уже кастом. Он неоднократно обсуждался на английском форуме и продолжает развиваться сейчас, уже третий год. Здесь на форуме подобная тема тоже обсуждалась, поищите, если нужно в HOWTOS.
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
Re: доработка AgentTicketPriority
ТС устраивает принцип вывода и зависимость данных между выбором в select'ах, реализованный в базовом OTRS в механизме принятия заявки по телефону
он лишь хочет чтобы в окне смены приоритета был аналогичный механизм, в 3.х.х с его слов это не так, в 4.х.х я предполагаю что это так (основываясь на беглом анализе пожеланий ТС, и просмотре кода шаблона), но безусловно могу ошибаться, поэтому предлагаю ТС, как понимающему в полном объёме свою собственную задачу - провести эксперимент на 4.х.х и поделиться его результатами с community
он лишь хочет чтобы в окне смены приоритета был аналогичный механизм, в 3.х.х с его слов это не так, в 4.х.х я предполагаю что это так (основываясь на беглом анализе пожеланий ТС, и просмотре кода шаблона), но безусловно могу ошибаться, поэтому предлагаю ТС, как понимающему в полном объёме свою собственную задачу - провести эксперимент на 4.х.х и поделиться его результатами с community
debian 7 / postgresql / otrs 4.0.6
-
- OTRS Гуру
- Сообщения: 5199
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: доработка AgentTicketPriority
Мы общались с ТС по данной задаче. Озвучили трудозатраты на реализацию - 2 часа. ТС хочет сам разобраться, остальные спецы понимают, что бесплатно обучать элементарной разработке нет времени. Так что пока - да, дневник.
По сути задачи - вооб
А вообще, по-хорошему, сама постановка задачи неправильная, некорреткная. По всем процессным логикам маршрутизация (перемещение в очередь) происходит всегда после приоритезации, категоризации и первичной диагностики. Так что ТС выдумал себе проблему на ровном месте и героически её преодолевает.
Сейчас ТС скажет - это так начальство решило ! Можно открыть книжку по ITIL и ткнуть носом начальство в workflow-процессов управления инцидентами или обращениями, и заняться чем-то более полезным
По сути задачи - вооб
И задачу Вы не правильно понимаете. Я понимаю и могу решить, но мои разработчики денег стоят. И эта задача одинаково решается и для 3.x и для 4.xvxb писал(а):и логика работы насколько я понимаю
А вообще, по-хорошему, сама постановка задачи неправильная, некорреткная. По всем процессным логикам маршрутизация (перемещение в очередь) происходит всегда после приоритезации, категоризации и первичной диагностики. Так что ТС выдумал себе проблему на ровном месте и героически её преодолевает.
Сейчас ТС скажет - это так начальство решило ! Можно открыть книжку по ITIL и ткнуть носом начальство в workflow-процессов управления инцидентами или обращениями, и заняться чем-то более полезным
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: доработка AgentTicketPriority
В этом вопросе в версии 3,3,8 всё также. Разница только в старом формате файлов dtl. Но ничто не мешает убрать этот include из AgentTicketPriority и впихнуть туда измененный AgentTicketActionCommon.AgentTicketPriority.tt содержит в себе include другого шаблона AgentTicketActionCommon.tt
Речь зашла о как раз приоретизации и категоризации поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" первой линией.По всем процессным логикам маршрутизация (перемещение в очередь) происходит всегда после приоритезации, категоризации и первичной диагностики.
Направление деятельности компании и структура департамента позволяет отказаться от первичной диагностики и сразу передать заявку в нужную очередь на вторую линию. Первая же линия не выполняет никакой диагностики, а занимается только распределением заявок согласно содержанию и предоставлением различных доступов.
Тем временем я попутно занимался ОТРС4.0.6
Новая телефонная заявка тут без изменений и с помощью ACL всё работает корректно и так как я хочу:
Выбираем тип - остальные поля пересчитываются под возможные значения согласно acl, далее выбираем очередь ИЗ ДОСТУПНЫХ.. потом сервисы, только те, которые могут быть назначены в вышеуказанную очередь согласно типа заявки...
Например: Типы заявок ОБСЛУЖИВАЕНИЕ и ИНЦИДЕНТ могут быть доступны для одной и той же очереди, но СЕРВИСЫ можно будет выбрать только согласно ТИПУ.
Например2: Есть очереди, которые не имеют сервисов, которые ИНЦИДЕНТ. Эти очереди с помощью ACL вообще не видны при выборе типа ИНЦИДЕНТ.
ACL рулит. Всё красиво.
Форма изменения Prioryty отличается интерфейсно в лучшую сторону. Поле ОЧЕРЕДЬ уже находится на нужном месте. Но логика работы полей такая же как и в 3,3,8. ACL нормально не отрабатывают этот весь блок связей из-за того, что поле ОЧЕРЕДЬ не такое, как в создании телефонной заявки. И именно это я пытаюсь побороть. Я пытался найти кусок кода, на работающей нормально для меня форме, отвечающий за этот блок и вставить его в нужное место. И считаю, что с Жавой, или Делфи с этим я бы справился точно. Но Перл пока мне не покоряется ((( А бабла никто не даст, хотя и эта форма редактирования заявки является реально принципиальной для руководства. Остаётся один вопрос: психануть потратить свои ползарплаты на 2 часа разработчиков Алексуса или продолжать грызть кактус. Причем я ни в коем случае не считаю ценник завышеным. Просто с оплатой труда в моей стране что-то не в порядке сейчас...
Думаю, что точно воспользуюсь советом №1: Внедрять буду 4.
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Получилось криво. Казнить нельзя помиловать. Перфразирую:Речь зашла о как раз приоретизации и категоризации поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" первой линией.
Речь зашла о как раз приоретизации и категоризации ПЕРВОЙ ЛИНИЕЙ поступившей заявки через почту или веб со всеми параметрами установленными "по-умолчанию" .
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Эту тему проходили. Эффект еще хуже. Им начинает хотеться после беглого прочтения документации вообще сказочных вещей. Приведу пример из жизни: Начальство заметило матрицу формирования приоритета заявки и тоже захотело такое прикрутить. По ихнему видению оператор первой линии должен выбрать при маршрутизации/создании заявкиМожно открыть книжку по ITIL и ткнуть носом начальство в workflow-процессов управления инцидентами
1. Критичность сервиса для ДАННОГО СУБЪЕКТА
2. Влияние случившегося НА БИЗНЕС
а автоматом по матрице формируется
3. Приоритет заявки
Браво. С того времени стараюсь умных книжек им не подсовывать. Не на ту почву...
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
Antony
AgentTicketPhone.tt
AgentTicketActionCommon.tt
это обработчики которые висят на смене Типа заявки
в телефонной
в приоритете
Dest - как раз то что в телефонной заявке отвечает за выбор очереди, в приоритете NewQueueID, могу предложить попробовать перечислить в массиве, передающемся в качестве третьего элемента в Core.AJAX.FormUpdate 'NewQueueID' и посмотреть что будет .)
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 %]
Код: Выделить всё
[% 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 %] ]);
debian 7 / postgresql / otrs 4.0.6
Re: доработка AgentTicketPriority
Dest нашел вчера, писал в дневнике)) Добавил в массив. Получилось так, что колёсико обновлялки возле поля ОЧЕРЕДЬ крутится, но фактически содержание элементов не меняется. Теперь пытаюсь найти связь в одноименных файлах .pm - то с чего я начинал.Dest - как раз то что в телефонной заявке отвечает за выбор очереди, в приоритете NewQueueID, могу предложить попробовать перечислить в массиве, передающемся в качестве третьего элемента в Core.AJAX.FormUpdate 'NewQueueID' и посмотреть что будет .)
Чувствую, что близко....
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
Re: доработка AgentTicketPriority
надо не Dest добавить а NewQueueID
в форме приоритета - не dest, а newqueueid отвечает за id очереди...
это если ограничиваться правками шаблонов
в форме приоритета - не dest, а newqueueid отвечает за id очереди...
это если ограничиваться правками шаблонов
debian 7 / postgresql / otrs 4.0.6
Re: доработка AgentTicketPriority
Добавил. Поведение такое же, как когда добавлял Dest:надо не Dest добавить а NewQueueID
при смене типа заявки колёсико обновлений крутится и возле ОЧЕРЕДИ, но на содержание не влияет.
так как я вставил NewQueueID в массив Core.AJAX.FormUpdate($('#Compose'), 'AJAXUpdate', 'TypeID' - колесико обновление поля очереди крутится только при изменении Типа заявки, а при изменении всех остальных полей остаётся статичным.
Самое примечательное, что при изменении Очереди - Сервисы подтягиваются согласно ACL. Только этого мне мало
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache
-
- OTRS Гуру
- Сообщения: 5199
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: доработка AgentTicketPriority
Пошла вторая неделя... Прогресс уже намечается .
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: доработка AgentTicketPriority
Думаю еще чего-то не хватает ACL
Например в AgentTicketPhone.pm есть такое
В AgentTicketCommon.pm похожего не нашел
Например в 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;
OTRS 4.0.6
Ubuntu 14
PostgreSQL
Apache
Ubuntu 14
PostgreSQL
Apache