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