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