При изучении типовых конфигураций, таких как 1С:ERP, 1С:Управление торговлей или 1С:Бухгалтерия, многие разработчики замечают интересную особенность: в текстах запросов динамических списков практически никогда не встречается ключевое слово РАЗРЕШЕННЫЕ. В то же время, при написании обычных запросов в программном коде или в консоли запросов, отсутствие этого слова при включенном RLS (Record Level Security) приводит к ошибке доступа, если у пользователя недостаточно прав на чтение всех записей таблицы.
В этой статье мы подробно разберем внутреннюю логику платформы «1С:Предприятие 8», выясним, каким образом данные фильтруются «за кулисами», и проанализируем влияние этого механизма на производительность системы.
Для начала проанализируем фундаментальное различие между объектом Запрос и объектом ДинамическийСписок. Главная задача динамического списка — обеспечить комфортную работу пользователя с большими массивами данных, не вызывая при этом критических ошибок интерфейса.
Рассмотрим стандартное поведение платформы: если мы выполним обычный запрос без слова РАЗРЕШЕННЫЕ под пользователем с ограниченными правами, платформа попытается прочитать все записи. Столкнувшись с первой же записью, на которую у пользователя нет прав, система выбросит исключение «Нарушение прав доступа». В случае с динамическим списком такое поведение было бы недопустимым, так как это привело бы к невозможности открыть форму списка.
Выясним причину: разработчики платформы изначально заложили в ДинамическийСписок логику, согласно которой режим РАЗРЕШЕННЫЕ включен по умолчанию и является неотключаемым. Это означает, что платформа самостоятельно модифицирует текст запроса перед его отправкой на СУБД, добавляя необходимые условия ограничения доступа.
Разберем по шагам, что происходит, когда динамический список подготавливает данные для отображения на экране:
WHERE (ГДЕ) или соединения JOIN, которые отсекают записи, запрещенные для текущего пользователя.ОсновнаяТаблица, платформа оптимизирует этот процесс, применяя ограничения максимально эффективно именно к этой таблице.Посмотрим на пример того, как выглядит исходный запрос разработчика в конфигураторе:
ВЫБРАТЬ
Ссылка,
Дата,
Номер,
Партнер,
СуммаДокумента
ИЗ
Документ.ЗаказКлиента
А теперь проанализируем, во что этот запрос превращается на уровне СУБД (упрощенно), когда платформа накладывает ограничения RLS (например, по группе доступа партнеров):
SELECT
T1.ID,
T1.Date,
T1.Number,
T1.PartnerID,
T1.Amount
FROM
Document_SalesOrder T1
WHERE
T1.PartnerID IN (SELECT AllowedID FROM AllowedPartnersTable WHERE UserID = @CurrentUserID)
Как мы видим, слово РАЗРЕШЕННЫЕ здесь не нужно в явном виде, так как платформа физически переписывает запрос, встраивая в него механизмы фильтрации.
Важно понимать, что эффективность автоматического добавления условий RLS напрямую зависит от настройки ОсновнаяТаблица. Рассмотрим ситуацию, когда это свойство заполнено.
Когда указана основная таблица, платформа «понимает» контекст данных. Это позволяет ей не просто добавить РАЗРЕШЕННЫЕ, но и использовать специализированные механизмы выборки данных (порционность, динамическое считывание при прокрутке). Если же запрос является сложным (например, объединение нескольких таблиц без явной основной), платформе становится сложнее определить, к каким именно полям применять ограничения, что может привести к снижению производительности.
Практический совет: всегда старайтесь указывать основную таблицу в динамическом списке, если это технически возможно. Это гарантирует наиболее корректную и быструю работу механизмов защиты данных.
В современных решениях, таких как 1С:ERP 2.5 или 1С:Бухгалтерия 3.0, используется так называемый «производительный RLS». Рассмотрим подробнее, как он взаимодействует с динамическими списками.
В этом режиме данные об ограничениях прав доступа кэшируются в специальных вспомогательных таблицах (регистрах сведений). При формировании данных для списка платформа выполняет левое соединение основной таблицы с этими таблицами прав. В такой архитектуре использование слова РАЗРЕШЕННЫЕ в тексте самого запроса становится избыточным «мусором». Даже если вы добавите его вручную, оптимизатор платформы проигнорирует его, так как логика ограничения уже реализована на уровне встраивания условий соединения с таблицами прав.
Проанализируем причины, по которым опытные разработчики и стандарты «1С» рекомендуют избегать явного написания этого слова в динамических списках:
ДинамическийСписок спроектирован как «безопасный» по определению. Явное указание режима, который и так включен принудительно, не несет функциональной нагрузки.Однако, стоит отметить, что в некоторых тиражных решениях (например, от компании БИТ) это слово иногда встречается. Чаще всего это связано с тем, что запрос копировался из Консоли запросов, где слово РАЗРЕШЕННЫЕ было необходимо для тестирования выборки под ограниченными правами, и разработчик просто забыл его удалить при переносе в конфигуратор.
Существует миф, что наличие или отсутствие слова РАЗРЕШЕННЫЕ влияет на скорость работы списка. Выясним истинную причину замедлений.
Само по себе слово в тексте запроса не замедляет работу. Замедление происходит из-за сложности самих правил RLS. Когда платформа добавляет условия ограничения, итоговый SQL-запрос может вырасти в десятки раз, обрастая многочисленными JOIN и сложными условиями в секции WHERE. Именно поэтому проверку скорости работы динамических списков необходимо проводить под пользователем с неполными правами — именно в этом случае вы увидите реальную картину производительности с учетом наложенных ограничений.
Подводя итог нашему анализу, можно выделить следующие ключевые моменты:
РАЗРЕШЕННЫЕ ко всем динамическим спискам.Таким образом, отсутствие слова РАЗРЕШЕННЫЕ в типовых конфигурациях — это не ошибка и не упущение, а прямое следование архитектурным принципам платформы и стандартам разработки фирмы «1С».