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