Как ограничить просмотр документов в 1С по дате с помощью механизма RLS

← На главную

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

Почему стандартный подход через константы может не работать

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


#Параметр(1) ИЗ Документ.#Параметр(1) КАК #Параметр(1), Константы КАК Константы
ГДЕ (#Параметр(1).Дата >= Константы.ДатаЗапретаБух)

Разберем, почему такой подход часто приводит к неудаче или падению производительности:

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

Анализ главной ошибки: Тестирование под полными правами

Проанализируем ситуацию, когда разработчик пишет верный код, но не видит результата. В сообщении №12 автор упоминает, что зашел в систему с «полными правами» для проверки. Важно помнить: для пользователя с ролью ПолныеПрава (или установленным признаком «Администрирование» в некоторых версиях) механизм RLS игнорируется платформой полностью. Это сделано для того, чтобы администратор всегда имел доступ к данным для обслуживания системы.

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

Рекомендуемое решение: Использование параметров сеанса

Наиболее правильным и производительным способом является использование Параметров сеанса. Параметр сеанса инициализируется один раз при старте программы и хранится в памяти, что позволяет RLS-запросу работать максимально быстро. Выясним, как реализовать это по шагам.

Шаг 1. Создание параметра сеанса. Создадим в конфигураторе объект ПараметрыСеанса с именем ДатаОграниченияПросмотра и типом Дата.

Шаг 2. Инициализация значения. В модуле сеанса пропишем установку этого параметра. Мы можем брать значение из константы, которую будет редактировать администратор.


Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    Если ТребуемыеПараметры = Неопределено Тогда
        // Инициализация при старте системы
        ПараметрыСеанса.ДатаОграниченияПросмотра = Константы.ДатаЗапретаБух.Получить();
    КонецЕсли;
КонецПроцедуры

Шаг 3. Написание условия RLS в роли. Теперь в тексте ограничения для права «Чтение» у нужного документа мы можем обратиться к этому параметру напрямую, используя символ амперсанда &.

ГДЕ Дата >= &ДатаОграниченияПросмотра

Посмотрим на этот запрос. Он предельно прост, лаконичен и не требует сложных соединений таблиц. Платформа подставит значение параметра сеанса непосредственно в SQL-запрос.

Особенности работы с несколькими ролями

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

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

Как проверить, работает ли RLS в принципе?

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

ГДЕ ЛОЖЬ

Если после этого пользователь перестанет видеть вообще все документы данного вида в журнале — значит, RLS настроен верно и работает. Если же документы по-прежнему видны, значит:

У пользователя есть другая роль, разрешающая доступ без ограничений.
У пользователя есть полные права.
Вы настраиваете ограничение на право «Просмотр», а нужно на «Чтение» (или наоборот, в зависимости от версии платформы и режима работы).

Обработка пустых дат и нюансы журналов

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


ГДЕ (Дата >= &ДатаОграниченияПросмотра И Дата <> ДАТАВРЕМЯ(1, 1, 1))
    ИЛИ (&ДатаОграниченияПросмотра = ДАТАВРЕМЯ(1, 1, 1))

Такая конструкция позволит избежать скрытия данных в случае, если дата запрета в константе вообще не установлена.

Также помните о Журналах документов. Даже если вы ограничили просмотр конкретного типа документа, его ключевые поля (дата, номер) могут быть видны в общем журнале, если на сам объект ЖурналДокументов не наложены аналогичные ограничения. В современных конфигурациях на базе БСП (Библиотека стандартных подсистем) рекомендуется использовать типовые механизмы доступа, однако базовые принципы RLS остаются неизменными.

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