Зачем в RLS используются конструкции ГДЕ ЛОЖЬ для прочих полей и ГДЕ ИСТИНА для стандартных реквизитов?

← На главную

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

<Прочие поля> ГДЕ ЛОЖЬ
Ссылка, ВерсияДанных, Номер, Дата, Проведен, ПометкаУдаления ГДЕ ИСТИНА

В этой статье мы подробно разберем, какую задачу решает данная комбинация условий, почему здесь используются конструкции ГДЕ ЛОЖЬ и ГДЕ ИСТИНА, и как эти настройки влияют на стабильность работы интерфейса, кэширование данных и производительность СУБД.

Понятие поколоночного ограничения доступа в 1С

По умолчанию механизмы RLS в платформе «1С:Предприятие» работают по строкам (ограничивают доступ к конкретным экземплярам документов или справочников по определенным условиям). Однако платформа также поддерживает и так называемое поколоночное (выборочное) ограничение прав. Оно позволяет разграничить доступ к отдельным реквизитам одного и того же объекта.

Рассмотрим ситуацию, когда в системе есть документ, содержащий строго конфиденциальные коммерческие сведения (например, ЗарплатаКВыплате или УсловияПродаж). Обычному пользователю категорически запрещено видеть содержимое этих документов. Но что произойдет, если этот конфиденциальный документ выбран в качестве аналитики (субконто) на счете учета или указан как документ-основание в платежном поручении, к которому у пользователя есть полный доступ?

Если полностью закрыть доступ к конфиденциальному документу на уровне роли (просто сняв галочку Чтение), то в форме платежного поручения или в отчетах вместо названия документа-основания пользователь увидит раздражающую и непонятную надпись <Объект не найден>. Это приводит к нарушению целостности восприятия интерфейса и мешает нормальной работе. Для решения этой проблемы и применяется рассматриваемый нами паттерн.

Анатомия конструкции <Прочие поля> ГДЕ ЛОЖЬ

Давайте проанализируем первую строку настройки RLS:

<Прочие поля> ГДЕ ЛОЖЬ

В терминах настройки прав «1С» поле <Прочие поля> объединяет в себе все реквизиты объекта метаданных, которые не были явно перечислены в других правилах ограничения для этой же роли. Сюда входят реквизиты шапки (суммы, контрагенты, ответственные, склады), табличные части со всеми их реквизитами, а также дополнительные сведения.

Конструкция ГДЕ ЛОЖЬ интерпретируется платформой и СУБД как заведомо невыполнимое условие (аналог WHERE 1=0 в SQL-запросе). Это означает следующее:

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

Таким образом, мы гарантируем абсолютную конфиденциальность внутренней информации документа.

Анатомия конструкции со списком реквизитов ГДЕ ИСТИНА

Теперь обратим внимание на вторую строку настройки:

Ссылка, ВерсияДанных, Номер, Дата, Проведен, ПометкаУдаления ГДЕ ИСТИНА

Здесь мы явно перечисляем ключевые системные и стандартные реквизиты документа. Конструкция ГДЕ ИСТИНА транслируется платформой в СУБД как всегда выполняющееся условие (аналог WHERE 1=1 в SQL). Это дает пользователю безусловное право на чтение перечисленных полей для абсолютно любого документа данного вида в базе данных.

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

Зачем нужны Ссылка, Номер и Дата?

Реквизиты Ссылка, Номер и Дата критически важны для визуализации объекта в интерфейсе программы:

Формирование представления: Представление любого документа в «1С» собирается по шаблону: ИмяДокумента + " № " + Номер + " от " + Дата (например, "Реализация товаров и услуг № 0005 от 12.01.2026"). Благодаря тому, что эти три поля открыты, платформа может собрать и показать пользователю красивую, понятную ссылку вместо битой надписи <Объект не найден>. Пользователь поймет, на какой именно документ ссылается его платежка или отчет.
Ввод по строке и автоподбор: Если пользователю нужно выбрать документ в качестве аналитики, он может начать вводить его номер с клавиатуры. Так как поля Номер и Дата доступны для чтения, платформа выполнит поиск в базе данных и предложит нужный документ в списке автоподбора.

Зачем нужна ВерсияДанных?

Поле ВерсияДанных (системное поле DataVersion в терминах СУБД) является служебным, и программисты редко обращаются к нему в прикладном коде напрямую. Однако для платформы «1С:Предприятие 8.3» это поле имеет колоссальное значение:

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

Зачем нужны реквизиты Проведен и ПометкаУдаления?

Эти два булевых поля отвечают за визуальное отображение состояния документа в списках, формах выбора и отчетах:

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

Пример технической реализации RLS

Рассмотрим, как данное ограничение транслируется платформой «1С» на уровень СУБД. Когда пользователь формирует запрос к списку документов, платформа автоматически модифицирует исходный запрос разработчика, внедряя в него условия из RLS.

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


ВЫБРАТЬ
    Реализация.Ссылка КАК Ссылка,
    Реализация.Номер КАК Номер,
    Реализация.Дата КАК Дата
ИЗ
    Документ.РеализацияТоваровУслуг КАК Реализация

Платформа переведет его в SQL-запрос для СУБД примерно в следующем виде:


SELECT
    T1._IDRRef,
    T1._Number,
    T1._Date_Time
FROM
    _Document150 T1
WHERE
    1=1 -- Это условие ГДЕ ИСТИНА для разрешенных полей

Запрос выполнится успешно и мгновенно. Однако, если недобросовестный или просто любопытный пользователь попытается в консоли запросов обойти ограничение и прочитать сумму документа:


ВЫБРАТЬ
    Реализация.СуммаДокумента КАК Сумма
ИЗ
    Документ.РеализацияТоваровУслуг КАК Реализация

Платформа подставит в SQL-запрос ограничение для группы «прочих полей»:


SELECT
    T1._Fld5230 -- Поле СуммаДокумента
FROM
    _Document150 T1
WHERE
    1=0 -- Это условие ГДЕ ЛОЖЬ для прочих полей

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

Взаимодействие с механизмами БСП (Библиотека стандартных подсистем)

Проанализируем, как этот паттерн соотносится с современными стандартами разработки. В Библиотеке стандартных подсистем (БСП) реализован механизм так называемого производительного RLS (ограничение доступа на основе специальных ключей доступа, хранящихся в регистрах сведений). При его использовании ручное прописывание подобных условий ГДЕ ЛОЖЬ и ГДЕ ИСТИНА в каждой роли уходит в прошлое.

Разработчики БСП создали готовые шаблоны ограничений. Например, шаблон #ДляОбъекта("") автоматически выполняет всю необходимую работу под капотом. Тем не менее, понимание базовой логики работы платформенного RLS критически важно в следующих случаях:

Вы ведете разработку в «самописной» конфигурации без использования БСП.
Вам необходимо создать уникальную, узкоспециализированную роль с тонкой настройкой прав, выходящей за рамки стандартных сценариев БСП.
Вам требуется провести расследование причин медленной работы запросов или выявить источники ошибок доступа Access Violation у пользователей с ограниченными правами.

Использование связки <Прочие поля> ГДЕ ЛОЖЬ и открытых стандартных реквизитов ГДЕ ИСТИНА — это проверенное временем, классическое и очень элегантное решение. Оно позволяет соблюсти строгий баланс между абсолютной безопасностью коммерческих данных и удобством, красотой и отзывчивостью пользовательского интерфейса «1С:Предприятия».