Почему не работает ограничение на уровне записей (RLS) для организаций в 1С:УНФ и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1С:Управление нашей фирмой IT и автоматизация бизнеса
← На главную

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

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

Разберем фундаментальный принцип работы прав: Кумулятивность ролей

Первое, что мы должны проверить при возникновении проблем с RLS — это состав ролей пользователя. В системе 1С права работают по принципу «Разрешено всё, что разрешено хотя бы одной ролью». Если у пользователя подключено несколько профилей или ролей, и в одной из них настроено ограничение по организации, а в другой — дан полный доступ к этому же объекту без RLS, то система предоставит полный доступ.

Проанализируем ситуацию по шагам:

  1. Откроем карточку пользователя в разделе Настройки — Настройки пользователей и прав.
  2. Проверим список назначенных профилей групп доступа. Если профилей несколько, велика вероятность конфликта.
  3. Воспользуемся встроенным отчетом «Права доступа». Этот отчет позволяет увидеть, какая именно роль дает право на «Чтение» или «Просмотр» искомого объекта (например, справочника Организации) без ограничений.

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

Проанализируем наличие реквизита «Организация» в объекте

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

В этом случае стандартный механизм БСП не сможет «понять», к какой организации относится запись. Для решения этой проблемы в УНФ применяются следующие подходы:

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

Выясним влияние привилегированного режима и предопределенных элементов

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

В УНФ многие серверные модули, отвечающие за заполнение документов и обработку данных, выполняются с установленным флагом Привилегированный. Когда код выполняется в этом режиме, система игнорирует любые настройки RLS. Если выпадающий список в документе формируется программно внутри такого модуля, пользователь увидит все организации, даже если на уровне базы данных ему запрещено их читать.

Посмотрим на пример кода, который может обходить RLS:


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

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

Проверим режим работы RLS: «Производительный» против «Совместимого»

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

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

  1. Перейдем в Обслуживание — Регламентные задания.
  2. Найдем задание «Обновление данных о правах доступа».
  3. Запустим его принудительно. Система пересчитает ключи доступа, и новые ограничения вступят в силу.

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

Настройка видимости в выпадающих списках

Часто пользователь жалуется, что RLS «не работает», потому что он видит название организации в поле ввода, хотя не может открыть её карточку. Это происходит из-за разделения прав на Чтение и Просмотр.

Разберем, как правильно настроить ограничения в шаблоне:

Если мы хотим, чтобы в документах в поле «Организация» отображались только доступные значения, необходимо убедиться, что в Группе доступа пользователя на закладке «Организации» установлено значение «Все запрещены, кроме выбранных», и в список добавлены только легитимные организации.

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

Подводя итог нашему анализу, для решения проблемы с RLS в УНФ мы рекомендуем придерживаться следующего алгоритма:

  1. Исключить наличие «лишних» ролей у пользователя через отчет «Права доступа».
  2. Убедиться, что в справочнике Организации настроен вид доступа и заполнены разрешенные значения.
  3. Проверить наличие функциональной опции «Вести учет по нескольким организациям» — если она выключена, механизмы RLS могут игнорироваться.
  4. Запустить обновление ключей доступа через регламентное задание.
  5. Если ограничение нужно для конкретного выпадающего списка, проверить, не заполняется ли он в привилегированном модуле.

Соблюдение этих шагов позволит корректно изолировать данные организаций и обеспечить информационную безопасность в базе 1С:УНФ.

← На главную