В процессе работы с 1С:Документооборот 3.0 пользователи могут столкнуться с ситуацией, когда инициатор процесса получает на почту уведомление следующего содержания: «Не все участники процесса имеют права на предметы: Сотрудники: [Список сотрудников] не имеют прав на предмет...». При этом на практике оказывается, что все указанные согласующие прекрасно видят документ, могут его редактировать и успешно выполняют свои задачи. Рассмотрим подробнее, почему возникает это противоречие и как правильно настроить систему, чтобы избежать подобных «ложноположительных» предупреждений.
Проанализируем логику работы 1С:ДО 3.0 при старте процесса. В момент, когда пользователь нажимает кнопку «В обработку», система запускает алгоритм проверки прав доступа для всех участников, указанных в схеме процесса (согласующих, исполнителей, утверждающих). Это необходимо для того, чтобы процесс не «завис» на полпути, когда очередь дойдет до сотрудника, который физически не сможет открыть документ.
Однако в версии 3.0 архитектура прав претерпела значительные изменения. Основная причина возникновения рассматриваемой ошибки кроется в настройке «Запретить автоматическое расширение доступа» в карточке Вид документа. Разберем, что происходит при включении этой опции:
Таким образом, мы имеем дело с особенностью логики: проверка видит отсутствие прав в текущий момент, но не учитывает, что они появятся в будущем по мере движения процесса.
Разберем еще один технический нюанс. В 1С:Документооборот 3.0 расчет прав доступа выполняется асинхронно. Это означает, что после любого изменения (старт процесса, добавление участника) система ставит задачу в очередь фонового задания Пересчет прав доступа.
Существует временной лаг (от нескольких секунд до нескольких минут) между действием пользователя и обновлением реальных таблиц доступа в базе данных. Если уведомление о проверке прав уходит мгновенно, оно может зафиксировать старое состояние системы до того, как фоновый процесс завершил расчет. В результате пользователь получает письмо об ошибке, а через 10 секунд заходит в документ и видит, что права уже есть.
Часто настройку «Запретить автоматическое расширение доступа» используют для того, чтобы скрыть документы от лишних глаз, например, от участников проекта, которые имеют доступ ко всем документам проекта по умолчанию. Рассмотрим, как решить эту задачу более корректными способами, не вызывая конфликтов в системе.
Способ 1. Использование Рабочих групп
Вместо жесткого запрета на расширение прав, рекомендуется использовать механизм Рабочих групп документа. Рассмотрим алгоритм:
Способ 2. Настройка Грифы доступа
Если определенный вид документов не должны видеть участники проектов или сотрудники определенных подразделений, проанализируем возможность применения Грифов доступа. Это наиболее надежный механизм отсечки. Если у пользователя в профиле доступа не указан соответствующий гриф (например, «Конфиденциально»), он не увидит документ, даже если является участником проекта, к которому привязан файл.
Способ 3. Уточнение политик доступа по контексту
Посмотрим на настройки в разделе Настройки доступа — Политики доступа. В 1С:ДО 3.0 можно настроить доступ так, чтобы права предоставлялись не «скопом» на все документы проекта, а только при наличии определенной роли. Если убрать из политик общие правила доступа для участников проектов к данному виду документа, то потребность в галочке «Запретить автоматическое расширение» отпадет сама собой.
С точки зрения методологии 1С, данное поведение не считается багом. Это информационное сообщение, которое предупреждает инициатора о потенциальных рисках. Если вы сознательно используете динамическое распределение прав, это уведомление можно игнорировать, однако для комфортной работы пользователей лучше пересмотреть архитектуру прав доступа, используя Политики и Рабочие группы вместо запретов на расширение.
Подведем итог: для устранения ложных уведомлений проверьте настройки вида документа. Если ваша цель — конфиденциальность, используйте рабочие группы и уберите ограничение на автоматическое расширение прав, чтобы система могла корректно отрабатывать штатные механизмы проверки при запуске бизнес-процессов.