Policy Acknowledgement Перед запуском кампании подготовьте разрешения на развёртывание, доступ к исходному содержимому и роли продукта. Одобрение разрешений Microsoft Graph и назначение ролей продукта — отдельные задачи.
Доступ для развёртывания и настройки
Решение поставляется как пакет SPFx для SharePoint Online. Процедура установки пакета описана в KB10035. Как установить продукт Vitextra в SharePoint Online. Пользователь, выполняющий первоначальную настройку, должен иметь возможность администрировать выбранный сайт хранения и создавать необходимые списки. Для создания нового сайта также требуется соответствующее разрешение в клиенте.
До настройки группы администраторов Policy Admin использует резервный доступ для владельцев сайта. После назначения группы администрирование продукта определяется членством в ней. Роли продукта не дают автоматически права редактирования страниц SharePoint или развёртывания приложений клиента.
Разрешения Microsoft Graph
Пакет решения запрашивает следующие разрешения Microsoft Graph:
| Разрешение | Использование в продукте |
|---|---|
User.Read.All | Профили сотрудников и сведения об организационной структуре. |
GroupMember.Read.All | Членство в группах для аудиторий и ролей. |
Directory.Read.All | Данные каталога для поиска сотрудников и групп. |
Mail.Send | Ручные напоминания по электронной почте из почтового ящика текущего пользователя. |
Попросите администратора клиента одобрить запросы пакета в принятом в организации процессе управления доступом SharePoint к API. Если элементы выбора сотрудников или групп не загружают данные, проверьте одобрение этих разрешений перед изменением правил аудитории.
Разрешения центра политик и содержимого
Назначьте группы ролям и примените разрешения в Policy Admin. Все веб-части должны подключаться к одному нужному центру политик. Сотрудникам также нужен доступ к исходному содержимому: указание URL в карточке политики не предоставляет права на файл, страницу или внешний сайт.
Для управляемого доступа используйте явно выбранные группы Entra ID или SharePoint на сайте центра политик. Не считайте вариант Все пользователи с лицензией проверкой лицензии каждого пользователя: текущая логика определения роли не проверяет индивидуальные лицензии.
Проверяйте каждый уровень доступа отдельно
Для работающего внедрения нужны несколько независимых видов доступа. Развёртывание пакета и управление политиками могут выполнять разные люди, а сотруднику не нужны права развёртывания для чтения назначения. Разделение обязанностей помогает диагностировать ошибку без предоставления широких административных прав в качестве обходного решения.
| Уровень доступа | Полезная приёмочная проверка | Типичное последствие ошибки |
|---|---|---|
| Пакет и страница | Нужный пользователь загружает опубликованную страницу и веб-часть. | Приложение недоступно или не отображается. |
| Каталог | Уполномоченный оператор находит нужных сотрудников и группы. | Могут не работать средства выбора, аудитория или определение ролей. |
| Данные центра | Учётная запись читает записи, необходимые её роли. | Страница открывается, но загрузка политик или назначений завершается ошибкой. |
| Исходное содержимое | Сотрудник открывает документ или сайт напрямую. | У видимой карточки политики может быть недоступное содержимое. |
| Запись доказательств | Пилотный сотрудник проходит настроенный путь записи. | Чтение работает, но подтверждение не сохраняется. |
| Иерархия подчинения | В каталоге указаны ожидаемые отношения с руководителями. | Команда руководителя может быть неполной или отличаться от ожидаемой. |
Проводите проверки с типичными учётными записями. Администратор, который одновременно является владельцем сайта, может успешно работать благодаря повышенным правам SharePoint, даже если обычный сотрудник получит ошибку. Аналогично, владелец политики в нескольких группах ролей не заменяет тестовую учётную запись с ограниченной ролью автора.
Подготовьте передачу внедрения в сопровождение
Зафиксируйте выбранный URL центра, стартовую страницу сотрудников, страницу чтения, группы ролей и расположение источников. Определите ответственных за сопровождение каждого элемента. Владелец политики должен знать, к кому обратиться при перемещении файла, а администратор поддержки — отличать проблему перехода по страницам от ошибки записи через сервис без восстановления всей схемы внедрения с нуля.
Перед пилотом проверьте идентификатор типичного сотрудника и его руководителя в каталоге. Кампании сохраняют сведения о сотруднике и руководителе в назначениях. Последующие изменения каталога не означают, что каждое поле старого назначения переписано. Поэтому реорганизация требует проверки отчётности команды, а не только возможности входа сотрудника.
Для ручных почтовых напоминаний проверьте оператора, который действительно будет их отправлять. Приложение использует его почтовый ящик, тогда как автоматические уведомления зависят от отдельной конфигурации сервиса. Одобрение запроса API, связанного с почтой, само по себе не проверяет ящик, доставку конкретному получателю или фоновый сервис.
Храните результаты этих проверок вместе со сведениями о внедрении. При сообщении об ошибке укажите затронутую учётную запись, центр и страницу, операцию и время. Это полезнее общего утверждения «разрешения одобрены», поскольку каждый уровень может работать или не работать независимо.
Сервис и режим записи
Для режима Service необходимы доступный URL сервиса и успешная проверка согласия администратора. Согласие для сервиса оформляется отдельно от одобрения разрешений Graph пакета SPFx. Автоматические напоминания, эскалации и постоянная обработка аудитории требуют отдельного сервисного компонента; сохранение настроек само по себе не запускает эти задачи.
❗ Важно
В режиме Direct сотрудники получают права внесения изменений в списки назначений и подтверждений. Перед использованием реальных данных сотрудников изучите KB10500. Как настроить роли и разрешения Policy Acknowledgement и KB10509. Хранение данных Policy Acknowledgement: режимы Direct и Service. Фильтры веб-частей и нацеливание на аудиторию не заменяют разрешения на данные.
