Как ограничить доступ к складу в 1С без использования RLS и избежать ошибок в расширениях

← На главную

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

Почему RLS и расширения конфликтуют

Рассмотрим ситуацию, когда при включенном RLS в расширениях начинают возникать ошибки вида «у пользователя недостаточно прав на исполнение операции над базой данных». Проанализируем основные причины такого поведения системы:

Аддитивность прав: В платформе 1С права работают по принципу объединения. Если одна роль разрешает чтение склада без условий, а другая ограничивает его через RLS, то в итоге пользователю будет разрешено всё. Чтобы ограничение сработало, оно должно быть прописано во всех ролях, назначенных пользователю, имеющих право на чтение справочника Склады.
Отсутствие ключевого слова РАЗРЕШЕННЫЕ: Когда код в расширении (например, при печати этикеток) выполняет запрос к базе данных, он может пытаться прочитать все записи таблицы. Если в запросе не указано ВЫБРАТЬ РАЗРЕШЕННЫЕ, система при попытке доступа к любой «запрещенной» по RLS записи прервет выполнение операции с критической ошибкой.
Конфликт метаданных: Если объект добавлен в расширение, платформа начинает особым образом объединять таблицы прав основной базы и расширения. Любая неточность в описании прав в расширении может «перекрыть» или некорректно дополнить правила основной конфигурации.

Способ 1: Использование программных отборов в формах (Альтернатива RLS)

Если механизм RLS вызывает слишком много ошибок или существенно замедляет работу базы, мы можем прибегнуть к программному ограничению видимости данных. Это не является «жестким» ограничением на уровне СУБД, но для большинства бизнес-задач этого достаточно. Рассмотрим, как реализовать отбор по конкретному складу в формах списков документов и справочников.

Для управляемых форм мы можем использовать событие ПриСозданииНаСервере. Разберем пример кода, который устанавливает фиксированный отбор, который пользователь не сможет отключить самостоятельно:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Определим склад, к которому нужно разрешить доступ
    НужныйСклад = Справочники.Склады.НайтиПоНаименованию("Основной склад");
    
    // Работаем с динамическим списком (обычно это реквизит "Список")
    ЭлементОтбора = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
    ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Склад");
    ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.Равно;
    ЭлементОтбора.ПравоеЗначение = НужныйСклад;
    ЭлементОтбора.Использование = Истина;
    ЭлементОтбора.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Недоступный;

КонецПроцедуры

В обычных формах (толстый клиент) логика аналогична, но используется объект Отбор самого списка в событии ПередОткрытием или настройка в свойствах элемента формы.

Способ 2: Настройка параметров выбора в документах

Чтобы пользователь не мог выбрать «чужой» склад в документах (например, в Реализации товаров или Поступлении), мы можем ограничить выпадающий список выбора. Рассмотрим, как это сделать без изменения кода, используя свойства метаданных:

Откроем нужный документ в конфигураторе.
Найдем реквизит Склад.
В свойствах реквизита найдем пункт Параметры выбора.
Установим фиксированный отбор (например, по конкретному реквизиту пользователя или подразделению).

Если склад должен определяться динамически при открытии формы, используем следующий код в расширении для формы документа:


&НаКлиенте
Процедура ПриОткрытииПосле(Отказ)
    // Ограничиваем выбор склада только одним значением
    ФиксированныйСклад = ПолучитьСкладТекущегоПользователя();
    ЭлементОтбора = Новый Структура("Ссылка", ФиксированныйСклад);
    Элементы.Склад.ПараметрыВыбора = Новый ФиксированныйМассив(Новый Массив); // Очистка, если нужно
    Элементы.Склад.ВыборПоСтроке = Ложь;
КонецПроцедуры

Способ 3: Использование привилегированного режима для обхода ошибок

Выясним причину ошибки «недостаточно прав» при печати. Если пользователю запрещено видеть склады, но для формирования этикетки или накладной системе нужно прочитать данные этого склада, возникает конфликт. В расширении мы можем временно повысить права текущего сеанса для выполнения конкретной операции.

Проанализируем пример функции в модуле расширения, которая формирует данные для печати:


Функция ПолучитьДанныеДляПечати(МассивСсылок) Экспорт
    
    // Включаем привилегированный режим, чтобы RLS не блокировал чтение
    УстановитьПривилегированныйРежим(Истина);
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   РеализацияТоваровУслуг.Склад.Наименование КАК СкладНаименование,
        |   РеализацияТоваровУслуг.Склад.Адрес КАК АдресСклада
        |ИЗ
        |   Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
        |ГДЕ
        |   РеализацияТоваровУслуг.Ссылка В(&МассивСсылок)";
    
    Запрос.УстановитьПараметр("МассивСсылок", МассивСсылок);
    Результат = Запрос.Выполнить().Выгрузить();
    
    // Обязательно отключаем, если это не конец процедуры
    УстановитьПривилегированныйРежим(Ложь);
    
    Возврат Результат;
    
КонецФункции

Важно: Привилегированный режим работает только на стороне сервера. Это позволяет расширению получить данные «в обход» ограничений пользователя, не меняя его основные права.

Способ 4: Проверка аддитивности ролей

Если склады все равно видны, несмотря на настроенный RLS, нам необходимо провести аудит ролей пользователя. В 1С есть полезный инструмент для этого — консоль запросов или отчет по правам доступа (в БСП).

Разберем алгоритм проверки:

Зайдите в карточку пользователя в режиме «1С:Предприятие».
Посмотрите список назначенных ролей.
В конфигураторе проверьте каждую из этих ролей. Если хотя бы в одной из них у справочника Склады стоит галочка «Просмотр» или «Чтение» без значка карандаша (означающего условие RLS), то пользователь будет видеть все склады.
Особое внимание уделите ролям типа «Полные права», «Чтение базовой НСИ» или «Просмотр всей нормативно-справочной информации».

Итоги и рекомендации

Для новичка в 1С настройка полноценного RLS в связке с расширениями может оказаться слишком сложной задачей из-за нюансов работы платформы. Мы рекомендуем:

Если задача стоит только в удобстве интерфейса (чтобы пользователь не путался в складах) — используйте программные отборы в формах.
Если нужно исключить ошибки в печатных формах — оборачивайте код формирования запросов в УстановитьПривилегированныйРежим(Истина).
Всегда используйте ВЫБРАТЬ РАЗРЕШЕННЫЕ в запросах, если в системе включен или планируется RLS.
Для жесткого ограничения доступа лучше использовать механизмы БСП (Библиотеки стандартных подсистем), такие как «Управление доступом», которые позволяют настраивать ограничения по группам доступа без написания сложных запросов RLS вручную.

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