Проект расширения стандартных оповещений AX 4.0

[Ivanhoe]

Выкладываю проект с расширениями стандартных оповещений AX 4.0 SP2 EE.

Новые возможности:
1. Создание правил оповещений:
1.1. Указание группы пользователей - оповещение получат все пользователи группы. Обязательность поля "Код пользователя" сохранена, проверка на права доступа также оставлена стандартная - по стандартному пользователю.
1.2. Указание поля или метода исходной таблицы, содержащей код пользователя - оповещение получит соответствующий пользователь. Поле указывается в виде %createdBy%, метод - виде %method()%. Проверки на валидность поля или метода нет.
1.3. Использование мета-тегов в Теме и Сообщении. Можно указать поле или метод записи для подстановки в Тему или Сообщение оповещения. Пример: %itemId% или %getPrice()%.
2. Расширение формы просмотра оповещений:
2.1. Добавлена группа с фильтрами - группа видна только пользователям с правами на ключ AdminSetup. Удобно просматривать "чужие" или "удаленные" оповещения.
2.2. Добавлены поля "Тип" (показывает как был выбран адресат - по пользователю, по группе или из исходной записи) и "Код группового оповещения" - если оповещение для группы пользователей - ссылка на базовое оповещение.
3. Исправление стандарта:
3.1. Исправлен переход к источнику оповещения для таблиц с несколькими составными индексами.
4. Создание оповещений из кода:
4.1. Класс EventInboxCreate - создание оповещений (включая почтовые) из кода. Пример использования - см. джоб tutorialCreateInbox.
4.2. Джоб tutorialCreateAlert - программное создание оповещения (без почты) работой напрямую с таблицами оповещений.

Проект выкладывается для ознакомления и использования для собственных нужд
Все функции протестированы, но 100% гарантии не даю =)
Если есть замечания или пожелания - пишите.

[wojzeh]

спасибо большое за этот проект!

рекомендую всё же инициировать значение переменной в методе Execute классов EventActionAlert и EventActionEmail:

    UserId                  userId = eventRule.UserId;

иначе это приводит к исключительной ситуации здесь

 if (SysUserInfo::find(userId, false) && !confind(users, userId))

когда система пытается продублировать запись существующего текущего пользователя.

[Ivanhoe]

Цитата:

Сообщение от wojzeh

...
иначе это приводит к исключительной ситуации здесь

 if (SysUserInfo::find(userId, false) && !confind(users, userId))

когда система пытается продублировать запись существующего текущего пользователя.

Спасибо за отзыв!!!
Я думаю, лучше сделать так:

if (userId && SysUserInfo::find(userId) && !confind(users, userId))

, т.е. если пользователь из исходной записии не настроен, то и не проверять ничего.

[wojzeh]

вся красота кроётся внутри метода SysUserInfo::find()

[Ivanhoe]

Ну так если первое условие false, Аксапта дальше уже ничего не делает.

[wojzeh]

к тебе вопросов нет - ты чист!

думаю вот, как сделать, чтобы письма усылались не только на пользователей аксапты, но и по полям типа Employee или вообще, по любым электропочтам.

[wojzeh]

1.2. Указание поля или метода исходной таблицы, содержащей код пользователя - оповещение получит соответствующий пользователь. Поле указывается в виде createdBy, метод - виде method() (знак % не нужен!)

[Ivanhoe]

Насчет других типов полей - либо расширять функциональность и проверять тип переданного поля (например на UserID, EmplId - соответственно обрабатывать, все остальное - ругаться, что некорректное поле), либо использовать метод на таблице - который вернет именно UserId.

По поводу произвольной почты - сейчас сделано по аналогии со стандартом, чтобы можно было перейти из почтового сообщения к оповещению или прямо в нужную форму аксапты, а для этого нужен EventInbox.
Наверное, можно сделать один EventInbox "общим" и на него ссылаться для всех остальных email, не привязанных к пользователю аксапты. Если же нужно только оповестить, без перехода в AX, то доработка не сложная, делали на проектах.

[wojzeh]

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

[sukhanchik]

Цитата:

Сообщение от wojzeh

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

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

[wojzeh]

как работает группа пользователей (EventRule.UserGroupId), я понимаю - мой вопрос о поле EventInbox.GroupEventInboxId - оно зачем?

[Ivanhoe]

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

На развитие думал про такую возможность:
В AX2009 в рамках документооборота есть понятие согласование и задача. При этом назначение задачи могут получить несколько пользователей, но выполнять ее нужно только один раз (одному сотруднику) - для этого пользователь нажимает кнопку "Принять" - т.е. уведомляет остальных, что он взял задачу на себя и остальным ее выполнять не надо (наскока я помню, в системе остальные оповещения просто будут удалены). В 4.0, предлагаю, сделать также - добавить признак правила оповещения "Задача" и по этому признаку давать возможность нажать кнопку "Принять", после чего все остальные оповещения этой группы надо либо удалить, либо пометить как-нибудь.

[wojzeh]

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

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

нарисовал пока вот так, "жёстко". (фрагмент метода класса)

static str getFieldValueFromCode(str _fieldByCode, common _buffer)
...
 // if the table exists
    if (bufferTable)
    {
        parentBuffer = _buffer;
        // the table here is the "parent" table to _buffer
        // it comes to a parent table: we need to locate one
        if (tId != _buffer.TableId)
        {
            // Realised for Sales and Purchase orders only
            // Sales orders
            if ((tId == tableNum(SalesTable)) && (_buffer.TableId == tableNum(SalesLine)))
            {
                parentBuffer = SalesTable::find(SalesLine::findRecId(_buffer.RecId).SalesId);
            }
            // Purchase orders
            if ((tId == tableNum(PurchTable)) && (_buffer.TableId == tableNum(PurchLine)))
            {
                parentBuffer = PurchTable::find(PurchLine::findRecId(_buffer.RecId).PurchId);
            }
        }
...

провернуть такой же трюк на таблице ProdJournalBOM, которая связана с ProdJournalTable не получается...

[Ivanhoe]

Цитата:

Сообщение от wojzeh

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

Хм, сам когда написал, понял что не понятно. Попробую еще раз
Как работает стандарт:
0. Общий фреймворк обработки записанных событий:
1. запускает создание оповещение в EventInbox.
2. по записи из п.1 запускает создание почтового сообщения.

Т.е. п.1 про п.2 ничего не знает.

После того, как мы вклинились в п.1 и наделали кучку дополнительных оповещений, система переходит к п.2 и передает параметром только основное оповещение, т.к. ничего не знает про наши дополнительные оповещения.

Соответственно, чтобы создать почту по всем дополнительным оповещениям нам нужен был признак для их поиска - все оповещения, которые связаны с основным оповещением.

По поводу вашей задачи - не совсем понятно, чего вы хотите добится - можете с точки зрения пользователя объяснить?

[wojzeh]

теперь понял. спасибо!

моя задача в том, чтобы, например, при изменении поля в SalesLine уведомлять сотрудника (SalesResponsible), указанного в SalesTable (в родительской таблице).

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

[Ivanhoe]

Для данной задачи я предполагал использовать методы на таблице-источнике. Создайте метод на таблице строк, который вернет нужного пользователя. В общем случае это более универсальное решение - мало ли надо проверить, что ответственный сейчас в отпуске и вместо него нужно отправить оповещение его заместителю?

[wojzeh]

я беру проблему более общо: например, если мы хотим использовать поля из родительской таблицы в тэгах сообщения.

%SalesTable.DeliveryAddress% по изменению чего-нибудь в SalesLine

[Ivanhoe]

Так для этого и сделана поддержка методов таблицы. Используйте SalesLine.DeliveryAddress() - так проще, чем писать явные связи между определенными таблицами.

[wojzeh]

нет, это концептуальный момент для меня в плане универсальности.

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

кстати, в момент создания правила на форме с несколькими таблицами эти связи "находятся" - их видно в верхней части, в запросе.

[Ivanhoe]

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

Допустим, нужно отследить тот же SalesLine, но информацию нужно взять из группы договора - т.е. SalesLine - SalesTable - RContractTable - RContractCode - вы хотите написать универсальный алгоритм раскрутки такой цепочки?