Кого включит ad hoc аварийное MC-оповещение: запрошенные и применённые критерии
Формулировка инициатора требует проверки результата
Руководитель хочет оповестить сотрудников, соответствующих заданным условиям, например находящихся в согласованной зоне работ. Для ad hoc аварийного MC-оповещения клиент передаёт критерии либо их понятное обозначение. Затем сервер проверяет полномочия и определяет список участников.
Важно различать исходное намерение и фактически применённые условия. Процедура допускает изменение содержимого критериев сервером в соответствии с локальной политикой. Поэтому запись «оповестить всех рядом» без сохранения результата не даёт воспроизводимого описания состава.
Как сделать испытание однозначным
В тестовой системе готовят несколько пользователей с заранее известным отношением к критерию. Один соответствует условиям, другой не соответствует, третий находится в согласованном пограничном случае. Конкретный способ определения принадлежности условиям выбирается проектом и поставщиком.
Инициатор отправляет запрос, после чего инженер сохраняет исходные критерии, результат проверки полномочий и возвращённые применённые критерии. Далее сопоставляет полученный состав с ожидаемым. Если локальная политика изменила отбор, её действие должно быть объяснимо уполномоченному специалисту.
Отсутствие детального текстового описания в одном окне клиента не доказывает отсутствия критерия. Он может передаваться обозначением предопределённого правила. Для сопровождения требуется согласованный справочник таких обозначений и возможность восстановить их смысл на момент события.
Идентификатор события тоже надо подтвердить
Если клиент не передал подходящий ID ad hoc группы, сервер назначает свой и возвращает его. Журналы и последующие операции следует связывать с фактически принятым идентификатором. Черновое обозначение на стороне инициатора не всегда достаточно.
Эта проверка особенно полезна при параллельных учебных оповещениях: одинаковое описание причины не означает одну группу. В карточке события сохраняют ID, инициатора, исходный и применённый отбор, а также временные отметки.
Что передать эксплуатации
Акт содержит доказательство определения состава и фактическую доставку выбранным тестовым клиентам. Отдельно проверяют отказ запроса от пользователя без нужных полномочий. В таком случае дальнейшие этапы процедуры не должны ошибочно считаться выполненными.
Последующий аварийный разговор зависит от конфигурации и проверяется отдельно. Формирование списка для оповещения не подтверждает его автоматический запуск.
Результат — понятная связь между намерением инициатора, решением сервера и действительными получателями. Она помогает объяснить отсутствие конкретного сотрудника в списке и не выдавать исходный текст запроса за точное описание применённых системой условий оперативного оповещения на объекте.
Запросы отправляются на наш e-mail из вашей почтовой программы.
