При работе в 1С:Документооборот 2.1 КОРП пользователи часто сталкиваются с ситуацией, когда система ведет себя избыточно "заботливо" в вопросах разграничения прав. Типичный сценарий: в рамках комплексного процесса один из исполнителей (например, Пользователь_2) должен прикрепить к процессу новый внутренний документ. Однако при попытке это сделать система выдает ошибку или, что еще более странно, пытается добавить других участников процесса (например, Пользователь_1) в рабочую группу этого документа с правами на Изменение, хотя им достаточно Чтения.
В этой статье мы подробно разберем, почему так происходит, как работает механизм расширения рабочей группы и какими способами можно ограничить права участников процесса до уровня "Только чтение".
Для начала проанализируем, почему Пользователь_1 вообще попадает в рабочую группу документа, к которому он, казалось бы, не имеет прямого отношения. В настройках Вида документа в шаблоне часто включена опция Автоматическое ведение состава участников рабочей группы.
Эта настройка работает следующим образом: как только документ становится предметом какого-либо процесса, система начинает отслеживать всех участников этого процесса. Чтобы процесс не "встал" из-за того, что очередной исполнитель не может открыть основной предмет, 1С:Документооборот автоматически включает всех участников (исполнителей, проверяющих, авторов) в рабочую группу документа.
Важный нюанс: логика системы по умолчанию часто настроена на "максимизацию" прав. Программа стремится гарантировать, что участник процесса сможет не только прочитать документ, но и, например, внести в него правки, добавить связи или заполнить фактические даты выполнения, если это предусмотрено его задачей. Именно поэтому вместо скромного права на Чтение часто проставляется Изменение.
Рассмотрим ситуацию глазами Пользователя_2, который пытается прикрепить созданный им внутренний документ к процессу. Почему он может столкнуться с трудностями?
Проблема кроется в правах на управление доступом. Когда Пользователь_2 прикрепляет предмет, система инициирует процедуру расширения рабочей группы (пытаясь добавить туда Пользователя_1). Для этого действия (изменение состава рабочей группы) Пользователь_2 сам должен обладать правами на администрирование этого конкретного документа или быть его автором. Если у него есть права только на создание и редактирование своего документа, но нет прав на "раздачу прав" другим, система не сможет автоматически расширить группу, и возникнет конфликт.
Главный инструмент управления правами в данном случае — это настройки самого комплексного процесса. Давайте разберем по шагам, где именно "зарыты" эти настройки:
Шаблон комплексного процесса, по которому запущена работа.Доступ.Изменение. Если мы хотим, чтобы участники конкретного этапа только видели документ, нам нужно принудительно установить там значение Чтение.Проанализируем ситуацию: если Пользователь_1 участвовал в этапе, где по умолчанию стояло право на изменение предметов, то при добавлении любого нового вспомогательного документа в этот процесс система будет пытаться "подтянуть" его права до того уровня, который указан в настройках его этапа.
Посмотрим на глобальные настройки, которые влияют на это поведение. В разделе Настройка и администрирование — Настройка программы — Права доступа существует важная опция: Изменять права доступа объектов при изменении участников.
Если эта опция включена, система будет автоматически пересчитывать рабочие группы каждый раз, когда меняется состав участников процесса. Это обеспечивает актуальность прав, но иногда приводит к избыточному предоставлению полномочий, как в нашем случае.
Если типовых настроек недостаточно, в 1С:Документооборот КОРП предусмотрена возможность использования скриптов в схемах процессов. Рассмотрим пример логики, которую можно внедрить в событие Перед выполнением или в условия маршрутизации, чтобы более гибко управлять правами:
// Пример логики для ограничения прав в рабочей группе
// Данный код иллюстрирует принцип, а не является готовым решением
Если ИмяДействия = "Ознакомление" Тогда
// Устанавливаем уровень доступа только на чтение для текущего предмета
Предмет.УровеньДоступа = УровниДоступа.Чтение;
КонецЕсли;
Использование подобных вставок позволяет переопределить стандартное поведение системы, когда она пытается выдать права на Изменение всем подряд. Однако к этому методу стоит прибегать только в крайнем случае, когда административные настройки шаблонов не помогают.
Еще один способ сделать систему более предсказуемой — использовать Роли исполнителей вместо указания конкретных пользователей. При использовании ролей механизмы расчета прав работают через дополнительные регистры сведений, что иногда позволяет избежать жесткого прописывания прав Изменение в карточке рабочей группы конкретного документа.
Подводя итог, если вы столкнулись с тем, что система требует дать лишние права участникам процесса, выполните следующие действия:
Доступ для предметов на всех этапах стоит корректное значение (Чтение там, где редактирование не требуется).Пользователь_2), имеет достаточно полномочий для изменения прав доступа, иначе автоматика будет "спотыкаться".Таким образом, мы выяснили, что поведение системы обусловлено стремлением обеспечить бесперебойность бизнес-процесса, но через детальную настройку Шаблонов комплексных процессов и Доступа к предметам эту избыточность можно и нужно ограничивать.