Разрешенные в запросе 1С: как работает ключевое слово РАЗРЕШЕННЫЕ

Ключевое слово РАЗРЕШЕННЫЕ в языке запросов 1С заставляет платформу учитывать ограничения доступа к данным (RLS) при выполнении запроса. Без него запрос возвращает все записи независимо от прав пользователя, а с ним — только те строки, которые текущему пользователю разрешено видеть согласно настроенным ролям.

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

Неправильное применение РАЗРЕШЕННЫЕ — частая причина двух противоположных проблем: либо пользователь видит лишние данные (нарушение безопасности), либо запрос работает медленно из-за сложных подставляемых условий. Понимание механики позволяет осознанно выбирать, где ограничение обязательно, а где оно избыточно.

Что делает ключевое слово РАЗРЕШЕННЫЕ

Когда в тексте запроса указано РАЗРЕШЕННЫЕ, платформа перед отправкой запроса в СУБД модифицирует его: к условиям выборки добавляются ограничения из шаблонов RLS, заданных для ролей текущего пользователя. Например, если менеджеру разрешено видеть только документы своей организации, платформа дописывает условие на поле Организация автоматически.

Если ни одна роль пользователя не содержит ограничений на уровне записей для выбираемых таблиц, РАЗРЕШЕННЫЕ фактически ничего не меняет — запрос вернёт все данные, но небольшие накладные расходы на анализ прав всё равно возникнут. Если ограничения есть, итоговый SQL-запрос может существенно усложниться: в него подставляются соединения с таблицами параметров доступа и вложенные условия.

Важно понимать, что РАЗРЕШЕННЫЕ работает только в паре с настроенными правами. Само по себе слово не создаёт защиту — оно лишь активирует уже существующие ограничения. Если администратор не настроил RLS, добавление РАЗРЕШЕННЫЕ не даст никакого эффекта по безопасности.

Синтаксис и место в тексте запроса

Ключевое слово ставится сразу после ВЫБРАТЬ, до перечисления полей. Также оно применяется в иерархических запросах и запросах с итогами — во всех случаях позиция одна и та же: в начале оператора выборки.

ВЫБРАТЬ РАЗРЕШЕННЫЕ
Документы.Ссылка,
Документы.Контрагент,
Документы.Сумма
ИЗ
Документ.РеализацияТоваровУслуг КАК Документы
ГДЕ
Документы.Дата >= &НачалоПериода

В запросах с объединениями РАЗРЕШЕННЫЕ указывается в каждой части ОБЪЕДИНИТЬ отдельно — ограничение из первой части не распространяется на последующие автоматически. Это частая причина утечки данных: разработчик добавил РАЗРЕШЕННЫЕ в первый подзапрос и забыл про остальные.

Во временных таблицах и вложенных запросах слово также указывается независимо для каждой выборки. Если данные проходят через цепочку временных таблиц, ограничение достаточно применить на первом уровне — в последующих выборках уже отфильтрованный набор можно читать без повторного РАЗРЕШЕННЫЕ, что ускорит запрос.

Когда РАЗРЕШЕННЫЕ обязательно, а когда вредно

Правило выбора строится на одном вопросе: увидит ли конечный пользователь результат этого запроса напрямую или через отчёт? Если да — РАЗРЕШЕННЫЕ обязательно, иначе пользователь сможет получить данные, закрытые его правами, просто открыв отчёт или обработку.

Обратная ситуация — служебные операции: проведение документов, расчёт итогов, обмены данными, фоновые задания, которые формируют данные для системы, а не для глаз пользователя. Здесь РАЗРЕШЕННЫЕ не только бесполезно, но и опасно: документ может не провестись, потому что пользователю не разрешено видеть какие-то связанные записи, хотя для корректности учёта они нужны.

Маршрут решения

Как выбрать действие

Запрос формирует данные для отчёта, динамического списка или обработки, которую видит пользовательУкажите РАЗРЕШЕННЫЕ — иначе возможен показ закрытых данных

Запрос выполняется в проведении, расчёте себестоимости или обмене даннымиНе используйте РАЗРЕШЕННЫЕ — служебной логике нужны все данные

Запрос работает медленно и содержит РАЗРЕШЕННЫЕПроверьте шаблоны RLS в ролях и рассмотрите перенос ограничения на первый уровень временных таблиц

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

Динамические списки и отчёты СКД

В динамических списках флаг РАЗРЕШЕННЫЕ устанавливается отдельным свойством, и в типовых конфигурациях он включён по умолчанию. В схеме компоновки данных ограничение применяется автоматически на уровне набора данных — вмешательство разработчика обычно не требуется, но при написании собственного текста запроса в наборе данных стоит проверить, что слово присутствует.

Влияние на производительность

Подстановка условий RLS может превратить простой запрос в тяжёлый: платформа добавляет соединения с таблицами групп доступа, вложенные подзапросы и логические условия ИЛИ для каждой роли пользователя. Чем больше у пользователя ролей с ограничениями и чем сложнее шаблоны, тем тяжелее итоговый SQL.

Практические приёмы снижения нагрузки: применять РАЗРЕШЕННЫЕ один раз на первом уровне цепочки временных таблиц, не дублировать его во вложенных запросах, упрощать шаблоны RLS (избегать соединений внутри шаблона), а также проверять, не назначено ли пользователю избыточное количество ролей с пересекающимися ограничениями.

Признак проблемы с производительностью именно из-за RLS: запрос без РАЗРЕШЕННЫЕ выполняется быстро, а с ним — в разы медленнее. В этом случае стоит получить технологический лог или план запроса и посмотреть, какие условия подставила платформа.

Проверка результата и типичные ошибки

Проверить работу РАЗРЕШЕННЫЕ просто: выполните один и тот же запрос в консоли запросов под пользователем с полными правами и под пользователем с ограниченной ролью. Если строки различаются — ограничение работает. Если наборы одинаковы, хотя RLS настроен, проверьте, действительно ли слово стоит в нужной части запроса.

Отдельный сценарий — привилегированный режим. Внутри УстановитьПривилегированныйРежим(Истина) права не проверяются, и РАЗРЕШЕННЫЕ фактически игнорируется: запрос вернёт все записи. Это нормально для служебной логики, но опасно, если результат потом без фильтрации отдаётся пользователю.

Порядок внедрения в существующий запрос

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

1. 1
   Проверьте, что для таблиц запроса настроены роли с шаблонами ограничения доступа
2. 2
   Добавьте РАЗРЕШЕННЫЕ после ВЫБРАТЬ в каждой части запроса, включая все части ОБЪЕДИНИТЬ
3. 3
   Выполните запрос под пользователем с ограниченными правами и зафиксируйте набор строк
4. 4
   Сравните с результатом под полными правами — наборы должны различаться ровно на закрытые записи
5. 5
   Замерьте время выполнения: при сильной деградации анализируйте шаблоны RLS и план запроса

Контрольные точки

Как проверить результат

Результат под ограниченным пользователем

Норма

Видны только разрешённые ролью записи

Тревожный признак

Видны все записи или, наоборот, пропали нужные

Время выполнения запроса

Норма

Сопоставимо с вариантом без РАЗРЕШЕННЫЕ

Тревожный признак

Рост времени в разы без объективной причины

Проведение документов у обычного пользователя

Норма

Документы проводятся без ошибок доступа

Тревожный признак

Ошибки вида «нарушение прав доступа» при проведении

Все части ОБЪЕДИНИТЬ

Норма

РАЗРЕШЕННЫЕ стоит в каждой части

Тревожный признак

Слово есть только в первой части объединения

FAQ

РАЗРЕШЕННЫЕ замедляет запрос — что делать в первую очередь?

Начните с анализа шаблонов RLS в ролях пользователя: соединения и вложенные запросы внутри шаблона — главный источник тормозов. Затем убедитесь, что ограничение применяется один раз на первом уровне временных таблиц, а не дублируется в каждом подзапросе. Отключать РАЗРЕШЕННЫЕ в пользовательских отчётах нельзя.

Почему с РАЗРЕШЕННЫЕ пользователь всё равно видит все данные?

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

Нужно ли РАЗРЕШЕННЫЕ в запросах при проведении документа?

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

Работает ли РАЗРЕШЕННЫЕ в привилегированном режиме?

Фактически нет: в привилегированном режиме проверка прав отключена, и запрос вернёт все записи. Если результат такого запроса показывается пользователю, фильтрацию нужно реализовывать отдельно — либо выносить выборку за пределы привилегированного блока.

Чем РАЗРЕШЕННЫЕ отличается от РАЗЛИЧНЫЕ?

Это независимые ключевые слова: РАЗЛИЧНЫЕ убирает дубли строк из результата, а РАЗРЕШЕННЫЕ фильтрует записи по правам пользователя. Их можно использовать вместе: ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ — в таком порядке.

Нужно ли РАЗРЕШЕННЫЕ для пользователя с полными правами?

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