При работе в программе 1С:Документооборот (особенно в редакции 2.1) многие администраторы и бизнес-аналитики сталкиваются с неприятным парадоксом. Пользователь имеет полный доступ к внутреннему или входящему документу (например, через рабочую группу или политики доступа), но при попытке открыть вкладку «Процессы и задачи» он не видит ни одной задачи по этому документу, если сам не является непосредственным участником этих процессов.
Сегодня мы подробно разберем, почему так происходит, выясним внутренние механизмы работы платформы 1С на уровне ограничения доступа (RLS), проанализируем, почему стандартные настройки разрезов доступа не решают эту проблему, и рассмотрим практические варианты обхода этого ограничения как в версии 2.1, так и в обновленной редакции 3.0.
Давайте вместе разберем эту проблему по шагам и найдем наиболее оптимальное решение.
Для начала проанализируем, как устроена логика разграничения прав доступа в конфигурации «1С:Документооборот 2.1». Разработчики фирмы 1С изначально заложили в архитектуру программы жесткое разделение между объектами метаданных:
Программа автоматически вычисляет право доступа на чтение задачи (объект ЗадачаСсылка.ЗадачаИсполнителя) и бизнес-процесса только для следующего круга лиц:
Если пользователь имеет права на сам документ, но не входит в этот список «касания» по процессу, система с помощью механизма RLS (Row Level Security) на уровне СУБД просто скроет от него эти задачи. На вкладке «Процессы и задачи» в карточке документа такой пользователь увидит лишь пустой список.
В процессе обсуждения этой проблемы часто возникает предложение включить определенные опции в настройках программы. Рассмотрим этот момент подробнее, чтобы предостеречь вас от неверных действий.
Существует мнение, что если перейти по пути: Настройки программы -> Права доступа -> Используемые разрезы доступа и включить там нужный вид документа (например, внутренний), то это решит проблему. На самом деле это не так.
Почему этот способ не работает: Настройка «Используемые разрезы доступа» в 1С:ДО предназначена для дополнительного ограничения прав, а не для их расширения. Она позволяет сузить видимость документов (например, запретить видеть документы определенного вида пользователям из конкретной группы доступа). Обойти базовый жесткий алгоритм проверки прав на задачи RLS с помощью этой настройки невозможно. Даже после регулярного пересчета прав пользователи, не участвующие в процессе, все равно не увидят связанные задачи.
Если ваша конфигурация находится на поддержке и вы не планируете вносить изменения в программный код, рассмотрим административные и организационные обходные пути.
Вы можете добавить эту предопределенную роль в полномочия пользователя или создать для этого специальный профиль групп доступа.
Если круг лиц, которые должны видеть ход согласования или исполнения документов, заранее известен, мы можем автоматизировать этот процесс через шаблоны.
В настройках шаблона бизнес-процесса (например, «Согласование» или «Исполнение») добавьте нужных сотрудников или роли в список «Наблюдатели» или настройте автоматическую отправку им подзадачи типа «Ознакомление». В этом случае они станут официальными участниками процесса, и система автоматически предоставит им права на просмотр всех связанных задач.
В карточке запущенного бизнес-процесса автор или администратор может вручную открыть вкладку «Рабочая группа» процесса и добавить туда необходимых пользователей. Этот метод подходит для единичных случаев, когда доступ нужно предоставить точечно вручную.
Если административные методы вам не подходят, мы можем решить задачу с помощью небольшого расширения конфигурации. Это позволит не снимать основную программу с поддержки.
Основная идея доработки заключается в том, чтобы показывать дерево процессов и задач в карточке документа в привилегированном режиме (то есть без контроля прав RLS на уровне базы данных для задач), если у текущего пользователя есть права на чтение самого документа.
Давайте посмотрим на пример реализации. Мы можем перехватить процедуру заполнения дерева процессов на форме документа и выполнить запрос к задачам в привилегированном модуле.
Пример кода общего модуля расширения, выполняемого на сервере без контроля прав:
&НаСервере
Функция ПолучитьЗадачиПоДокументуПривилегированно(СсылкаНаДокумент) Экспорт
УстановитьПривилегированныйРежим(Истина);
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЗадачаИсполнителя.Ссылка КАК Задача,
| ЗадачаИсполнителя.Наименование КАК Наименование,
| ЗадачаИсполнителя.Исполнитель КАК Исполнитель,
| ЗадачаИсполнителя.СостояниеБизнесПроцесса КАК Статус
|ИЗ
| Задача.ЗадачаИсполнителя КАК ЗадачаИсполнителя
|ГДЕ
| ЗадачаИсполнителя.Предметы.Предмет = &Документ";
Запрос.УстановитьПараметр("Документ", СсылкаНаДокумент);
Возврат Запрос.Выполнить().Выгрузить();
КонецФункции
Используя этот метод, мы можем модифицировать форму карточки документа так, чтобы при переходе на вкладку процессов данные считывались через наш привилегированный запрос. Таким образом, если пользователь смог открыть сам документ (проверка прав на документ отработала штатно), он без проблем увидит весь ход его обработки.
Если вы планируете переход на новую редакцию 1С:Документооборот 3.0, то для вас есть отличная новость. Разработчики полностью пересмотрели концепцию работы с задачами и правами доступа, что практически полностью устранило эту проблему.
Рассмотрим, как это реализовано в новой версии:
Подводя итоги, мы можем составить следующий план действий в зависимости от вашей текущей ситуации: