Хочу победить "особенность" поведения подсистемы уведомлений

[Creative]

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

Пролог.
В системе создана очередь "для разбора", владельцем заявок в которой, при получении через постмастер или клиентский интерфейс, по умолчанию становится определённый агент (ID владельца по умолчанию, для обоих этих способов подачи заявки, можно определить в конфигурятнике).

Проблема
В итоге сложилась следующая ситуация. Агентом выполняющим предварительный разбор, является менеджер который до открытия заявки проверяет состояние взаимоотношений с клиентом (клиент на договоре, разовый, существует ли задолженность по оплате по документообороту и т.п.). Не спрашивайте почему этот процесс ещё не автоматизирован, сам мечтаю. Дополнительно он выполняет первичную классификацию по сервису, проверяет "качество" сообщения, наличие необходимых для продолжения работ сведений в заявке и т.д.
При появлении заявки в "очереди разбора" по результату действий постмастера или скрипта клиентского интерфейса упомянутый агент не получает уведомлений о поступлении новой заявки. Так как агент, в нашем случае, обрабатывает ещё много другой проходящей и поступающей информации, то складывается ситуация при которой информация поступающая по другим направлениям порой сваливается большой кучей и агент имеет меньше времени на то чтобы лишний раз "для подстраховки" просмотреть дашборд. В итоге агент не получает уведомления и заявки порой висят на разборе достаточно долго (30-40 минут).
При всём при этом, если заявка создана "изнутри" другим агентом в очереди менеджера, то уведомления приходят нормально.
Проблема не была сильно заметна на старте, но при возрастании объёмов её воздействие начало сказываться на производительности (и соответственно качестве)

Предполагаемый источник.
Экспериментальным путём было выявлено что при включении Ticket -> Core::Ticket -> AgentSelfNotifyOnAction уведомления начинают поступать. Правда при этом начинают поступать естественно "лишние" уведомления о своих же собственных действиях, для включения чего собственно эта опция и предназначена. То есть при отключенной опции система, согласно указанию, что владельцем заявки, созданной через клиентский интерфейс или принятой по почте является агент с определённым ID, считает что ему нет необходимости сообщать о заявке якобы созданной им же самим.

[Creative]

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

Неподходящие и уже опробованные решения.
Можно конечно поставить ответственным по умолчанию другого агента, но это не совсем положительно сказывается на истории. Так как работа очень оперативна и "забыть" назначить себя владельцем до выполнения перемещения менеджеру очень легко, и это не вопрос мотивации, работы у человека и так много, а переложить функции контроля пока невозможно по ряду причин. Плюс к этому, назначение другого владельца по умолчанию с последующим его автоматическим изменением через GA (как один из предполагаемых вариантов) вызовет появление опять же "лишних" уведомлений о действии "изменение владельца" которое фактически не связано ни с каким процессом передачи ответственности, а является просто костылём. Агент будет получать информацию не о поступлении заявки, а о действии в уже существующей (Момент создания заявки опять же получается не отслеживаемым)
Настраиваемые уведомления через "Уведомление о событии", тоже не есть решение, так как такие уведомления оседают в заявках. Лишние байты собираются в килобайты, потом мегабайты (ну вы меня поняли)
Да и в любом случае всё это обходные решения. А хотелось бы решить эту проблему.

Эпилог.
Проблема есть, источник известен, вероятное решение известно.
Нужен мозговой штурм и анализ кода. Сам завален текучкой, вздохнуть некогда.
Был бы посвободнее, наверное сам нашёл бы "отправную точку". Так как времени не хватает, прошу помощи у народа.

З.Ы. Лимит на мессадж сработал, поэтому двумя частями Без костылей нигде не обходится

[alexus]

Проблема выеденного яйца не стоит. Все входящие тикеты с портала и почты ставятся по дефолту на системного юзера. Затем планировщиком проставляется нужный агент. Уведомление уходит. Никаких проблем вообще.

[Creative]

А как, в плане уведомлений, система реагирует на смену владельца через GA?

Так как, если склоняться к варианту в котором заявка создаётся на админа (условного юзера) и автоматом переназначается на менеджера, возникает мысль о возможной проблеме с "двойными" уведомлениями. То есть менеджер должен, теоретически, получить уведомление о появлении заявки в своей очереди, "созданной" условным юзером, и после этого тут же получить уведомление о том, что условный юзер назначил владельцем такой-то заявки менеджера. Если оно так и получиться, то не комильфо.

[alexus]

Вы, похоже, принципиально не понимаете, как работают уведомления. Уведомления реагируют на СОБЫТИЕ. Все события прозрачно видны при настройке "уведомлений о событии". Перемещение тикета в очередь - событие, создание тикета - событие, назначение владельца - тоже событие. Каким образом генерируются эти события - не важно. Действия агента, планировщик, кастомные модули, письма клиента и т.д. - это все генераторы определенных событий.
Настраивайте для ваших агентов те события, которые Вам нужны. Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.

[Creative]

Вы, похоже, принципиально не понимаете, как работают уведомления. Уведомления реагируют на СОБЫТИЕ. Все события прозрачно видны при настройке "уведомлений о событии".

Алексей, я прекрасно понимаю принцип работы системы уведомлений, и уточнить хотел именно вот это

Каким образом генерируются эти события - не важно. Действия агента, планировщик, кастомные модули, письма клиента и т.д. - это все генераторы определенных событий.

то есть то, что система будет реагировать на действия планировщика так же, как и на действия живого агента.

Но при этом

Настраивайте для ваших агентов те события, которые Вам нужны.

вы говорите про "Уведомление о событии", а я про "Уведомление агентов", а в них как известно (в версии 3.1 по крайней мере) настраивается только содержание.

Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.

Это мне тоже всё известно.

На данный момент ситуация складывается следующая. Единственным более менее приемлемым вариантом, видимо, становится создание "дефолтного" агента, который и будет являться владельцем создаваемых в очереди менеджера заявок. Уведомление агента о создании тикета будет приходить. А вот с назначением владельцем менеджера придётся подумать. Либо делать это планировщиком, и при этом получать в довесок "лишнее" уведомление о назначении владельца (хотя можно его в принципе "рубануть" фильтрами на почтовом сервере), либо же как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне.

[alexus]

то есть то, что система будет реагировать на действия планировщика так же, как и на действия живого агента.

да, планировщик вызывает те же системные модули, которые устанавливают агентов, очереди, статусы и т.д.

а я про "Уведомление агентов", а в них как известно (в версии 3.1 по крайней мере) настраивается только содержание.

для них просто события уже предопределены

alexus писал(а):
Не забудьте, что у агентов есть еще и личные настройки для уведомлений, которые они себе сами могут дополнительно включить. Можно, кстати, их запретить для изменения.

Это мне тоже всё известно.

Это как раз и есть "Уведомления агентов"

создание "дефолтного" агента

Он уже есть - root@localhost - системный пользователь. Не стоит множить сущности.

А вот с назначением владельцем менеджера придётся подумать.

Это всегда полезно !

получать в довесок "лишнее" уведомление о назначении владельца

Для кого оно - "лишнее"?

как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне

Это как например? Ну просто абстрактно опишите.

[merkushov]

Андрей, вам, возможно подойдёт вариант с созданием собственного обработчика событий. Привяжите его к событию TicketCreate. Он будет отправлять уведомление Агенту, фактически, это будет обход флага AgentSelfNotifyOnAction для конкретно ваших условий.

Вам нужно создать свой обработчик по аналогии с Kernel/System/Ticket/Event/Test.pm и свой конфигурационный xml файл в каталоге ./Kernel/Config/Files/, для связки обработчика с событием.

[Creative]

Спасибо за наводку Виктор, поглядим чем эти модули богаты.
Я в поисках рыскал? пытаясь раскопать что-то в модулях с именами *notification*, а вот про ивент модули то и не подумал поглядеть.
В конфигах, так понимаю, нужно будет создавать блоки по типу Ticket::EventModulePost###500-NotificationEvent (или его соседей по разделу)

Для кого оно - "лишнее"?

Имелось ввиду, что вроде как событие назначения владельца в этом случае не вызвано действиями живого агента, поэтому менеджер друг за другом получит сначала newticket а потом owner уведомления. Вот второе то как раз и не к чему.

Creative писал(а):
как-то отталкиваться от выполняемых менеджером действий и привязывать к ним назначение агента владельцем на автоматическом уровне

Это как например? Ну просто абстрактно опишите.

Так как менеджер выполняет стандартные действия, например, перевести в состояние ожидания оплаты (для разовых заявок), применяя действие Note или после классификации передать в очередь специалистам (они у нас разбиты по обязанностям). Так вот при выполнении этих действий можно ведь кастомизировать модули (или решить путём настроек) так, чтобы агент выполняющий действие назначался владельцем автоматом. Например включить обязательный lock (при этом произойдёт смена владельца с системного юзера на менеджера), и совместить с заданием планировщика, который проверит, если заявка заблокирована менеджером не в своей очереди, то снять lock.

Это я к примеру. Пока не тестировал.

Тут ещё Виктор подкинул пищу для размышлений. Возможно я всё таки решу задачу в соответствии со своей задумкой. Будет дополнительный опыт в perl-е. 6)

[alexus]

Андрей, все гораздо проще!
Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###RequiredLock
Можно, конечно, и ивентовый модуль написать . Но так проще.

[Creative]

Андрей, все гораздо проще!
Ticket -> Frontend::Agent::Ticket::ViewNote
Ticket::Frontend::AgentTicketNote###RequiredLock

Дык и я о чём. Главное решить за какое действие удобнее зацепиться, чтобы остальные процессы не перебатонило.

Можно, конечно, и ивентовый модуль написать . Но так проще.

А вот это, если получится, поможет мне решить задачу именно так как я её решение описал в самом начале.
Хотя если не получится сейчас, оставлю пока "костыль" через блокировку, а как созрею, вернусь к первоначальной идее.

[ULiX]

Добавить свой обработчик в стандартный редактор конфигурации можно созданием своего XML в директории
/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.

[merkushov]

Посмотрите как используется параметр Transaction в других обработчиках событий. Не нашёл его использования
В общем, если память не изменяет, то в процессе работы процедуры Run (sub Run)? если вернуть 1 return 1; то следующий по алфавиту обработчик событий задействуется, если же вернуть 0, то ваш обработчик событий оборвет цепочку обработки событий.

Это интересно. Можете привести ссылку на код, где обрывается обработка событий при возвращении 0?
Мне кажется, что выполняются все обработчики события, независимо от того что вернул предыдущий обработчик