Хочу победить "особенность" поведения подсистемы уведомлений
Модератор: ykolesnikov
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Хочу победить "особенность" поведения подсистемы уведомлений
Обнаружил некоторую "избирательность" связанную с работой уведомлений.
Предлагаю помыслить коллективно, найти решение, и (по желанию) передать результат наших изысканий разработчику.
Пролог.
В системе создана очередь "для разбора", владельцем заявок в которой, при получении через постмастер или клиентский интерфейс, по умолчанию становится определённый агент (ID владельца по умолчанию, для обоих этих способов подачи заявки, можно определить в конфигурятнике).
Проблема
В итоге сложилась следующая ситуация. Агентом выполняющим предварительный разбор, является менеджер который до открытия заявки проверяет состояние взаимоотношений с клиентом (клиент на договоре, разовый, существует ли задолженность по оплате по документообороту и т.п.). Не спрашивайте почему этот процесс ещё не автоматизирован, сам мечтаю. Дополнительно он выполняет первичную классификацию по сервису, проверяет "качество" сообщения, наличие необходимых для продолжения работ сведений в заявке и т.д.
При появлении заявки в "очереди разбора" по результату действий постмастера или скрипта клиентского интерфейса упомянутый агент не получает уведомлений о поступлении новой заявки. Так как агент, в нашем случае, обрабатывает ещё много другой проходящей и поступающей информации, то складывается ситуация при которой информация поступающая по другим направлениям порой сваливается большой кучей и агент имеет меньше времени на то чтобы лишний раз "для подстраховки" просмотреть дашборд. В итоге агент не получает уведомления и заявки порой висят на разборе достаточно долго (30-40 минут).
При всём при этом, если заявка создана "изнутри" другим агентом в очереди менеджера, то уведомления приходят нормально.
Проблема не была сильно заметна на старте, но при возрастании объёмов её воздействие начало сказываться на производительности (и соответственно качестве)
Предполагаемый источник.
Экспериментальным путём было выявлено что при включении Ticket -> Core::Ticket -> AgentSelfNotifyOnAction уведомления начинают поступать. Правда при этом начинают поступать естественно "лишние" уведомления о своих же собственных действиях, для включения чего собственно эта опция и предназначена. То есть при отключенной опции система, согласно указанию, что владельцем заявки, созданной через клиентский интерфейс или принятой по почте является агент с определённым ID, считает что ему нет необходимости сообщать о заявке якобы созданной им же самим.
Предлагаю помыслить коллективно, найти решение, и (по желанию) передать результат наших изысканий разработчику.
Пролог.
В системе создана очередь "для разбора", владельцем заявок в которой, при получении через постмастер или клиентский интерфейс, по умолчанию становится определённый агент (ID владельца по умолчанию, для обоих этих способов подачи заявки, можно определить в конфигурятнике).
Проблема
В итоге сложилась следующая ситуация. Агентом выполняющим предварительный разбор, является менеджер который до открытия заявки проверяет состояние взаимоотношений с клиентом (клиент на договоре, разовый, существует ли задолженность по оплате по документообороту и т.п.). Не спрашивайте почему этот процесс ещё не автоматизирован, сам мечтаю. Дополнительно он выполняет первичную классификацию по сервису, проверяет "качество" сообщения, наличие необходимых для продолжения работ сведений в заявке и т.д.
При появлении заявки в "очереди разбора" по результату действий постмастера или скрипта клиентского интерфейса упомянутый агент не получает уведомлений о поступлении новой заявки. Так как агент, в нашем случае, обрабатывает ещё много другой проходящей и поступающей информации, то складывается ситуация при которой информация поступающая по другим направлениям порой сваливается большой кучей и агент имеет меньше времени на то чтобы лишний раз "для подстраховки" просмотреть дашборд. В итоге агент не получает уведомления и заявки порой висят на разборе достаточно долго (30-40 минут).
При всём при этом, если заявка создана "изнутри" другим агентом в очереди менеджера, то уведомления приходят нормально.
Проблема не была сильно заметна на старте, но при возрастании объёмов её воздействие начало сказываться на производительности (и соответственно качестве)
Предполагаемый источник.
Экспериментальным путём было выявлено что при включении Ticket -> Core::Ticket -> AgentSelfNotifyOnAction уведомления начинают поступать. Правда при этом начинают поступать естественно "лишние" уведомления о своих же собственных действиях, для включения чего собственно эта опция и предназначена. То есть при отключенной опции система, согласно указанию, что владельцем заявки, созданной через клиентский интерфейс или принятой по почте является агент с определённым ID, считает что ему нет необходимости сообщать о заявке якобы созданной им же самим.
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Re: Хочу победить "особенность" поведения подсистемы уведомл
Предлагаемое решение.
Считать, что заявки полученные через постмастер или клиентский интерфейс не являются созданными агентом "на разборе", и заставить считать так систему. Хотя если говорить правильнее, надо поймать момент обработки необходимости уведомления при создании заявки постмастером и скриптом клиентского интерфейса и убрать оттуда условие, проверяющее вышеупомянутую AgentSelfNotifyOnAction. Т.е. отправлять уведомления о создании заявки присвоенному ей владельцу безусловно.
Ну или как вариант не убрать что-то откуда-то, а наоборот добавить.
Неподходящие и уже опробованные решения.
Можно конечно поставить ответственным по умолчанию другого агента, но это не совсем положительно сказывается на истории. Так как работа очень оперативна и "забыть" назначить себя владельцем до выполнения перемещения менеджеру очень легко, и это не вопрос мотивации, работы у человека и так много, а переложить функции контроля пока невозможно по ряду причин. Плюс к этому, назначение другого владельца по умолчанию с последующим его автоматическим изменением через GA (как один из предполагаемых вариантов) вызовет появление опять же "лишних" уведомлений о действии "изменение владельца" которое фактически не связано ни с каким процессом передачи ответственности, а является просто костылём. Агент будет получать информацию не о поступлении заявки, а о действии в уже существующей (Момент создания заявки опять же получается не отслеживаемым)
Настраиваемые уведомления через "Уведомление о событии", тоже не есть решение, так как такие уведомления оседают в заявках. Лишние байты собираются в килобайты, потом мегабайты (ну вы меня поняли)
Да и в любом случае всё это обходные решения. А хотелось бы решить эту проблему.
Эпилог.
Проблема есть, источник известен, вероятное решение известно.
Нужен мозговой штурм и анализ кода. Сам завален текучкой, вздохнуть некогда.
Был бы посвободнее, наверное сам нашёл бы "отправную точку". Так как времени не хватает, прошу помощи у народа.
З.Ы. Лимит на мессадж сработал, поэтому двумя частями Без костылей нигде не обходится
Считать, что заявки полученные через постмастер или клиентский интерфейс не являются созданными агентом "на разборе", и заставить считать так систему. Хотя если говорить правильнее, надо поймать момент обработки необходимости уведомления при создании заявки постмастером и скриптом клиентского интерфейса и убрать оттуда условие, проверяющее вышеупомянутую AgentSelfNotifyOnAction. Т.е. отправлять уведомления о создании заявки присвоенному ей владельцу безусловно.
Ну или как вариант не убрать что-то откуда-то, а наоборот добавить.
Неподходящие и уже опробованные решения.
Можно конечно поставить ответственным по умолчанию другого агента, но это не совсем положительно сказывается на истории. Так как работа очень оперативна и "забыть" назначить себя владельцем до выполнения перемещения менеджеру очень легко, и это не вопрос мотивации, работы у человека и так много, а переложить функции контроля пока невозможно по ряду причин. Плюс к этому, назначение другого владельца по умолчанию с последующим его автоматическим изменением через GA (как один из предполагаемых вариантов) вызовет появление опять же "лишних" уведомлений о действии "изменение владельца" которое фактически не связано ни с каким процессом передачи ответственности, а является просто костылём. Агент будет получать информацию не о поступлении заявки, а о действии в уже существующей (Момент создания заявки опять же получается не отслеживаемым)
Настраиваемые уведомления через "Уведомление о событии", тоже не есть решение, так как такие уведомления оседают в заявках. Лишние байты собираются в килобайты, потом мегабайты (ну вы меня поняли)
Да и в любом случае всё это обходные решения. А хотелось бы решить эту проблему.
Эпилог.
Проблема есть, источник известен, вероятное решение известно.
Нужен мозговой штурм и анализ кода. Сам завален текучкой, вздохнуть некогда.
Был бы посвободнее, наверное сам нашёл бы "отправную точку". Так как времени не хватает, прошу помощи у народа.
З.Ы. Лимит на мессадж сработал, поэтому двумя частями Без костылей нигде не обходится
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
-
- OTRS Гуру
- Сообщения: 5204
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 94 раза
- Поблагодарили: 84 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
Проблема выеденного яйца не стоит. Все входящие тикеты с портала и почты ставятся по дефолту на системного юзера. Затем планировщиком проставляется нужный агент. Уведомление уходит. Никаких проблем вообще.
С уважением,
Алексей Юсов
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? Спросите меня как!
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Re: Хочу победить "особенность" поведения подсистемы уведомл
А как, в плане уведомлений, система реагирует на смену владельца через GA?
Так как, если склоняться к варианту в котором заявка создаётся на админа (условного юзера) и автоматом переназначается на менеджера, возникает мысль о возможной проблеме с "двойными" уведомлениями. То есть менеджер должен, теоретически, получить уведомление о появлении заявки в своей очереди, "созданной" условным юзером, и после этого тут же получить уведомление о том, что условный юзер назначил владельцем такой-то заявки менеджера. Если оно так и получиться, то не комильфо.
Так как, если склоняться к варианту в котором заявка создаётся на админа (условного юзера) и автоматом переназначается на менеджера, возникает мысль о возможной проблеме с "двойными" уведомлениями. То есть менеджер должен, теоретически, получить уведомление о появлении заявки в своей очереди, "созданной" условным юзером, и после этого тут же получить уведомление о том, что условный юзер назначил владельцем такой-то заявки менеджера. Если оно так и получиться, то не комильфо.
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
-
- OTRS Гуру
- Сообщения: 5204
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 94 раза
- Поблагодарили: 84 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
Вы, похоже, принципиально не понимаете, как работают уведомления. Уведомления реагируют на СОБЫТИЕ. Все события прозрачно видны при настройке "уведомлений о событии". Перемещение тикета в очередь - событие, создание тикета - событие, назначение владельца - тоже событие. Каким образом генерируются эти события - не важно. Действия агента, планировщик, кастомные модули, письма клиента и т.д. - это все генераторы определенных событий.
Настраивайте для ваших агентов те события, которые Вам нужны. Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.
Настраивайте для ваших агентов те события, которые Вам нужны. Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.
С уважением,
Алексей Юсов
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? Спросите меня как!
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Re: Хочу победить "особенность" поведения подсистемы уведомл
Алексей, я прекрасно понимаю принцип работы системы уведомлений, и уточнить хотел именно вот этоalexus писал(а):Вы, похоже, принципиально не понимаете, как работают уведомления. Уведомления реагируют на СОБЫТИЕ. Все события прозрачно видны при настройке "уведомлений о событии".
то есть то, что система будет реагировать на действия планировщика так же, как и на действия живого агента.alexus писал(а):Каким образом генерируются эти события - не важно. Действия агента, планировщик, кастомные модули, письма клиента и т.д. - это все генераторы определенных событий.
Но при этом
вы говорите про "Уведомление о событии", а я про "Уведомление агентов", а в них как известно (в версии 3.1 по крайней мере) настраивается только содержание.alexus писал(а):Настраивайте для ваших агентов те события, которые Вам нужны.
Это мне тоже всё известно.alexus писал(а):Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.
На данный момент ситуация складывается следующая. Единственным более менее приемлемым вариантом, видимо, становится создание "дефолтного" агента, который и будет являться владельцем создаваемых в очереди менеджера заявок. Уведомление агента о создании тикета будет приходить. А вот с назначением владельцем менеджера придётся подумать. Либо делать это планировщиком, и при этом получать в довесок "лишнее" уведомление о назначении владельца (хотя можно его в принципе "рубануть" фильтрами на почтовом сервере), либо же как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне.
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
-
- OTRS Гуру
- Сообщения: 5204
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 94 раза
- Поблагодарили: 84 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
да, планировщик вызывает те же системные модули, которые устанавливают агентов, очереди, статусы и т.д.Creative писал(а):то есть то, что система будет реагировать на действия планировщика так же, как и на действия живого агента.
для них просто события уже предопределеныCreative писал(а):а я про "Уведомление агентов", а в них как известно (в версии 3.1 по крайней мере) настраивается только содержание.
Это как раз и есть "Уведомления агентов"Creative писал(а):alexus писал(а):
Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.
Это мне тоже всё известно.
Он уже есть - root@localhost - системный пользователь. Не стоит множить сущности.Creative писал(а):создание "дефолтного" агента
Это всегда полезно !Creative писал(а):А вот с назначением владельцем менеджера придётся подумать.
Для кого оно - "лишнее"?Creative писал(а):получать в довесок "лишнее" уведомление о назначении владельца
Это как например? Ну просто абстрактно опишите.Creative писал(а):как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне
С уважением,
Алексей Юсов
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? Спросите меня как!
-
- OTRS Бывалый
- Сообщения: 310
- Зарегистрирован: 25 окт 2012, 15:06
- Откуда: Воронеж
- Поблагодарили: 2 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
Андрей, вам, возможно подойдёт вариант с созданием собственного обработчика событий. Привяжите его к событию TicketCreate. Он будет отправлять уведомление Агенту, фактически, это будет обход флага AgentSelfNotifyOnAction для конкретно ваших условий.
Вам нужно создать свой обработчик по аналогии с Kernel/System/Ticket/Event/Test.pm и свой конфигурационный xml файл в каталоге ./Kernel/Config/Files/, для связки обработчика с событием.
Вам нужно создать свой обработчик по аналогии с Kernel/System/Ticket/Event/Test.pm и свой конфигурационный xml файл в каталоге ./Kernel/Config/Files/, для связки обработчика с событием.
Меркушов Виктор, perl программист
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Re: Хочу победить "особенность" поведения подсистемы уведомл
Спасибо за наводку Виктор, поглядим чем эти модули богаты.
Я в поисках рыскал? пытаясь раскопать что-то в модулях с именами *notification*, а вот про ивент модули то и не подумал поглядеть.
В конфигах, так понимаю, нужно будет создавать блоки по типу Ticket::EventModulePost###500-NotificationEvent (или его соседей по разделу)
Это я к примеру. Пока не тестировал.
Тут ещё Виктор подкинул пищу для размышлений. Возможно я всё таки решу задачу в соответствии со своей задумкой. Будет дополнительный опыт в perl-е. 6)
Я в поисках рыскал? пытаясь раскопать что-то в модулях с именами *notification*, а вот про ивент модули то и не подумал поглядеть.
В конфигах, так понимаю, нужно будет создавать блоки по типу Ticket::EventModulePost###500-NotificationEvent (или его соседей по разделу)
Имелось ввиду, что вроде как событие назначения владельца в этом случае не вызвано действиями живого агента, поэтому менеджер друг за другом получит сначала newticket а потом owner уведомления. Вот второе то как раз и не к чему.alexus писал(а):Для кого оно - "лишнее"?
Так как менеджер выполняет стандартные действия, например, перевести в состояние ожидания оплаты (для разовых заявок), применяя действие Note или после классификации передать в очередь специалистам (они у нас разбиты по обязанностям). Так вот при выполнении этих действий можно ведь кастомизировать модули (или решить путём настроек) так, чтобы агент выполняющий действие назначался владельцем автоматом. Например включить обязательный lock (при этом произойдёт смена владельца с системного юзера на менеджера), и совместить с заданием планировщика, который проверит, если заявка заблокирована менеджером не в своей очереди, то снять lock.alexus писал(а):Creative писал(а):
как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне
Это как например? Ну просто абстрактно опишите.
Это я к примеру. Пока не тестировал.
Тут ещё Виктор подкинул пищу для размышлений. Возможно я всё таки решу задачу в соответствии со своей задумкой. Будет дополнительный опыт в perl-е. 6)
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
-
- OTRS Гуру
- Сообщения: 5204
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 94 раза
- Поблагодарили: 84 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
Андрей, все гораздо проще!
Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###RequiredLock
Можно, конечно, и ивентовый модуль написать . Но так проще.
Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###RequiredLock
Можно, конечно, и ивентовый модуль написать . Но так проще.
С уважением,
Алексей Юсов
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? Спросите меня как!
-
- OTRS Новобранец
- Сообщения: 132
- Зарегистрирован: 22 июн 2011, 14:33
- Откуда: Татарстан, Альметьевск
Re: Хочу победить "особенность" поведения подсистемы уведомл
Дык и я о чём. Главное решить за какое действие удобнее зацепиться, чтобы остальные процессы не перебатонило.alexus писал(а):Андрей, все гораздо проще!
Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###RequiredLock
А вот это, если получится, поможет мне решить задачу именно так как я её решение описал в самом начале.Можно, конечно, и ивентовый модуль написать . Но так проще.
Хотя если не получится сейчас, оставлю пока "костыль" через блокировку, а как созрею, вернусь к первоначальной идее.
Мозг человека обычно загружен лишь на 10% своей мощности, остальное - резерв для операционной системы.
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
OTRS 3.1.4; ITSM 3.1.6; Ubuntu Server 12.04 LTS
Андрей Ананьев
Re: Хочу победить "особенность" поведения подсистемы уведомл
Добавить свой обработчик в стандартный редактор конфигурации можно созданием своего XML в директории
/Kernel/Config/Files/
Пример:
Я там сразу с полями доп параметров делал
Названием
Ticket::EventModulePost###600-SamberiTicketFilter
Регламентируете порядок выполнения фильтров, выполняются в алфавитном порядке
к примеру так:
...
500-NotificationEvent
600-SamberiTicketFilter
900-EscalationIndex
...
Чтобы не терять свои модули в дебрях общих модулях создаем свой модуль в кустом папке
/opt/otrs/Custom/Kernel/System/Ticket/Event/SamberiTicketFilter.pm
В качестве шаблона можно использовать готовый
/opt/otrs/Kernel/System/Ticket/Event/Test.pm
Не забываем в самом модуле исправить название пакетного модуля в строке
Посмотрите как используется параметр Transaction в других обработчиках событий. Не нашёл его использования
В общем, если память не изменяет, то в процессе работы процедуры Run (sub Run)? если вернуть 1 return 1; то следующий по алфавиту обработчик событий задействуется, если же вернуть 0, то ваш обработчик событий оборвет цепочку обработки событий.
Таким образом, если разместить свой обработчик событий скажем с именем "499-MyNotificationEvent", то можно прервать работу стандартного обработчика событий "500-NotificationEvent" при нужных вам условиях вернув 0 в процессе выполнения процедуры Run.
/Kernel/Config/Files/
Пример:
Я там сразу с полями доп параметров делал
Код: Выделить всё
<?xml version="1.0" encoding="utf-8"?>
<otrs_config version="1.0" init="Application">
<ConfigItem Name="Ticket::EventModulePost###600-SamberiTicketFilter" Required="0" Valid="1">
<Description Translatable="1">"Samberi Events".</Description>
<Group>Ticket</Group>
<SubGroup>Core::Ticket</SubGroup>
<Setting>
<Hash>
<Item Key="Module">Kernel::System::Ticket::Event::SamberiTicketFilter</Item>
<Item Key="Transaction">1</Item>
<Item Key="Event"></Item>
<Item Key="State">new</Item>
<Item Key="OA">
<Hash>
<Item Key="Samberi12">ОА::Гиперы::С-12</Item>
<Item Key="Samberi13">ОА::Гиперы::С-13</Item>
<Item Key="Samberi14">ОА::Гиперы::С-14</Item>
<Item Key="Samberi15">ОА::Гиперы::С-15</Item>
</Hash>
</Item>
<Item Key="AHO">
<Hash>
<Item Key="Samberi12">ОЭиТО::ОЭиТО С-12</Item>
<Item Key="Samberi13">ОЭиТО::ОЭиТО С-13</Item>
<Item Key="Samberi14">ОЭиТО::ОЭиТО С-14</Item>
<Item Key="Samberi15">ОЭиТО::ОЭиТО С-15</Item>
</Hash>
</Item>
</Hash>
</Setting>
</ConfigItem>
</otrs_config>
Ticket::EventModulePost###600-SamberiTicketFilter
Регламентируете порядок выполнения фильтров, выполняются в алфавитном порядке
к примеру так:
...
500-NotificationEvent
600-SamberiTicketFilter
900-EscalationIndex
...
Чтобы не терять свои модули в дебрях общих модулях создаем свой модуль в кустом папке
/opt/otrs/Custom/Kernel/System/Ticket/Event/SamberiTicketFilter.pm
В качестве шаблона можно использовать готовый
/opt/otrs/Kernel/System/Ticket/Event/Test.pm
Не забываем в самом модуле исправить название пакетного модуля в строке
Код: Выделить всё
package Kernel::System::Ticket::Event::Test;
Посмотрите как используется параметр Transaction в других обработчиках событий. Не нашёл его использования
В общем, если память не изменяет, то в процессе работы процедуры Run (sub Run)? если вернуть 1 return 1; то следующий по алфавиту обработчик событий задействуется, если же вернуть 0, то ваш обработчик событий оборвет цепочку обработки событий.
Таким образом, если разместить свой обработчик событий скажем с именем "499-MyNotificationEvent", то можно прервать работу стандартного обработчика событий "500-NotificationEvent" при нужных вам условиях вернув 0 в процессе выполнения процедуры Run.
Я не флудер, у меня просто не получаются маленькие посты.
-
- OTRS Бывалый
- Сообщения: 310
- Зарегистрирован: 25 окт 2012, 15:06
- Откуда: Воронеж
- Поблагодарили: 2 раза
Re: Хочу победить "особенность" поведения подсистемы уведомл
Это интересно. Можете привести ссылку на код, где обрывается обработка событий при возвращении 0?ULiX писал(а):Посмотрите как используется параметр Transaction в других обработчиках событий. Не нашёл его использования
В общем, если память не изменяет, то в процессе работы процедуры Run (sub Run)? если вернуть 1 return 1; то следующий по алфавиту обработчик событий задействуется, если же вернуть 0, то ваш обработчик событий оборвет цепочку обработки событий.
Мне кажется, что выполняются все обработчики события, независимо от того что вернул предыдущий обработчик
Меркушов Виктор, perl программист