Как ограничить видимость и доступ к отдельным строкам табличной части документа в 1С?

В процессе разработки бизнес-приложений на платформе 1С:Предприятие часто возникает задача разграничения прав доступа. Например, требуется сделать так, чтобы руководитель филиала или подразделения видел в документе начисления премий только "своих" сотрудников, а данные чужих подразделений были скрыты.

Рассмотрим подробно, почему штатный механизм ограничения прав доступа (RLS) не позволяет скрыть строки табличной части, и разберем проверенные архитектурные и программные методы решения этой задачи.

Ограничение платформы: почему RLS не работает для отдельных строк ТЧ

Проанализируем работу механизма Record Level Security (RLS). На уровне платформы 1С:Предприятие ограничение прав доступа на уровне записей действует только на объекты информационной базы целиком (ссылочные объекты: документы, элементы справочников, или записи регистров). Наложить правило RLS непосредственно на отдельную строку табличной части невозможно.

Если прописать условие RLS с обращением к реквизиту табличной части документа, платформенный механизм сработает на весь документ целиком:

1. Документ станет полностью недоступен для чтения, если ни одна строка не отвечает условию.
2. Или документ будет виден целиком со всеми строками, если хотя бы одна строка удовлетворяет условию.

По этой причине реализация разграничения доступа к конкретным строкам внутри одного документа требует иных архитектурных и технических подходов.

Решение 1. Архитектурное деление документов по филиалам (Рекомендуемое)

Наиболее надежный и правильный подход с точки зрения методологии 1С — разбить ввод данных на отдельные документы по каждому филиалу или подразделению.

В документ добавляется шапочный реквизит Подразделение или Филиал. Настройка прав доступа настраивается стандартным механизмом RLS для объекта целиком.

Разберем пример простого условия ограничения прав (RLS) в роли на чтение/изменение документа:

ГДЕ Подразделение = &ТекущееПодразделение
 ИЛИ Организация = &ТекущаяОрганизация

При использовании этого подхода полностью исключаются проблемы целостности данных, а также упрощается работа расчетчиков и администраторов системы.

Решение 2. Разделение контура ввода и контура анализа данных

Рассмотрим паттерн проектирования, изолирующий создателей информации (расчетчиков) от ее потребителей (руководителей филиалов):

1. Ввод документов: Расчетчики работают с документами в полном объеме или по своим структурным подразделениям. Доступ к самим документам начислений ограничен и предоставляется только операторам и администраторам.
2. Проведение по регистрам: При проведении документа данные из табличной части записываются в соответствующий регистр сведений или регистр накопления.
3. Ограничение на регистр: Настройку RLS выполняем для записей регистра накопления/сведений по разрезу Подразделение.
4. Отчетность для руководителей: Потребители информации (руководители) не открывают сами документы, а получают информацию исключительно через отчеты, созданные на базе регистра. Благодаря RLS на регистр, в отчетах отображаются только доступные конкретному руководителю данные.

Решение 3. Программная фильтрация строк на управляемой форме

Если архитектура системы уже сформирована и разбить документы по подразделениям невозможно, применяют программное скрытие строк на управляемой форме.

Разберем порядок реализации этого способа:

1. В обработчике события ПриСозданииНаСервере скрывается стандартное отображение табличной части. На форму выводится динамически созданная таблица значений, куда копируются только строки, относящиеся к филиалу текущего пользователя.
2. Данные чужих филиалов сохраняются во временном хранилище или реквизите формы.
3. При вызове события ПередЗаписьюНаСервере выполняется слияние отредактированных пользователем строк с недоступными ему строками других филиалов, после чего итоговый набор данных записывается в документ.

Для предотвращения случайного редактирования чужих данных вместо полного скрытия строк также применяется условное оформление и проверка в событии ПриАктивизацииСтроки, где для элементов формы устанавливается флаг ТолькоПросмотр = Истина.

Критические риски и подводные камни программного скрытия строк

Выбирая решение с программным скрытием строк на форме, обязательно проанализируйте следующие риски:

1. Отсутствие реальной защиты данных: Скрытие строк на форме — это лишь визуальное ограничение. Пользователь с базовыми правами на чтение документа сможет увидеть данные чужих строк через консоль запросов, внешние отчеты или универсальный редактор объектов.
2. Конфликты параллельной работы: Если руководители двух разных подразделений одновременно откроют один и тот же документ, внесут изменения в свои видимые строки и сохранят документ, запись второго пользователя может перезаписать или затереть изменения первого.
3. Проблемы при проведении: Модуль проведения обрабатывает табличную часть целиком. Если в скрытой от пользователя строке чужого филиала содержит ошибку (например, не заполнена аналитика), документ не проведется, но пользователь не сможет понять и исправить причину ошибки на форме.
4. Несоответствие итогов: Итоги по колонкам табличной части (например, общая сумма начислений) на форме не будут совпадать с суммой только видимых строк, что вызывает вопросы у пользователей.

Резюме: Для создания безопасной и отказоустойчивой системы рекомендуется отказаться от скрытия строк ТЧ на форме в пользу разделения документов по подразделениям и использования RLS на уровне объектов и регистров учета.