О создании правил оповещения
Применимо к: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012
При создании правила оповещения необходимо учитывать следующие условия.
Создание правил оповещения
Новые или измененные правила оповещений принимаются только в том случае, если пользователи обладают доступом ко всем таблицам и полям, требуемым для использования правил.
Например, если пользователь создает правило для таблицы, относительно которой он обладает соответствующими разрешениями системы безопасности. Однако если разрешения доступа пользователя позже ограничены, у него нет доступа к таблице, на которую он создал правило.
Правило остается видимым в форме Управление правилами генерации оповещений, но никакие оповещения на основе этого правила не создаются и не отправляются пользователю.
Эта же ситуация возникает, если пользователь создает правило для таблицы, и в фильтре правила присутствует ссылка на другую таблицу. Если удалить или запретить разрешения пользователя относительно таблицы, на которую ссылается правило, правило оповещений пользователя становится устаревшим, и оповещения, соответствующие этому правилу, создаваться не будут.
Создание правил оповещений на основе шаблонов
Пользователь, которому требуется создать новое правило из шаблона, может выбрать шаблоны только для тех частей Microsoft Dynamics AX которые ему разрешено использовать.
Создание правил оповещений, включающих настройку запроса
Как правило, если все таблицы, перечисленные в форме запроса, имеют отношение с таблицей, которая первоначально выбрана, 1:n или n:1, специальные права и ограничения применяются к пользователю функции запроса. Когда оповещение создается с фильтром в форме запроса, те же права и ограничения применяются к владельцу правила.
Создание правил оповещений на основе внешних ключей
Правило на основе внешнего ключа не создает оповещений, если внешний ключ переименовывается в ходе операции переименования первичного ключа. Внешний ключ представляет собой поле, на которое ссылается одна форма, при условии, что это является первичным ключом в другой форме. Операция переименования первичного ключа предполагает, что поле переименовывается в форме, в которой оно создано.
Например, имеется Соглашение о сервисном обслуживании, которое присоединяется к группе Соглашений о сервисном обслуживании, которая называется "Дания". В форме Соглашения на обслуживание, настройте правило оповещений для Соглашение о сервисном обслуживании таким образом, чтобы получать оповещения если имя группы Соглашений о сервисном обслуживании "Дания" изменяется. Если имя группы Соглашений о сервисном обслуживании позже изменится на имя другой существующей группы, например "Швеция", вы получите оповещение. Однако вы не получаете оповещения, если имя группы Соглашений о сервисном обслуживании "Дания" изменено операцией переименования первичного ключа. Когда операция переименования первичного ключа используется, имя группы Соглашений о сервисном обслуживании изменено в форме, где группы настроены, форма Группы соглашений о сервисном обслуживании. Например, операция переименования первичного ключа может изменить имя группы Соглашений о сервисном обслуживании из "Дания" в "DK". Однако это изменение не запускает оповещение.
Виртуальные компании
Правила оповещений должны настраиваться по каждой компании в рамках виртуальной компании. Нельзя настраивать одно правило оповещений так, чтобы оно применялось более чем к одной компании в рамках виртуальной компании.
Удаленные пользователи
Если пользователь удален, все правила оповещений, владельцем которых является данный пользователь, также удаляются.
Если нужно удалить пользователя, но сохранить правило оповещений, созданное пользователем, от удаления, перед удалением пользователя необходимо изменить код пользователя правила оповещений. Либо, чтобы сохранить все правила, созданные пользователем, не удаляйте пользователя. Вместо этого просто отключите пользователя. Правила оповещений пользователя, который был отключен, а не удален, сохраняются.