Что значит «Разрешенные» в запросе 1С

Ключевое слово РАЗРЕШЕННЫЕ (в английском синтаксисе — ALLOWED) в языке запросов 1С указывает платформе, что выборку нужно ограничить только теми записями, к которым у текущего пользователя есть права доступа. Это касается как обычных прав на объекты (чтение, просмотр), так и ограничений доступа на уровне записей — механизма RLS (Record Level Security).

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

Конструкция записывается сразу после слова ВЫБРАТЬ: ВЫБРАТЬ РАЗРЕШЕННЫЕ Ссылка, Наименование ИЗ Справочник.Номенклатура. Дополнительно можно комбинировать её с ПЕРВЫЕ: ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 10 — платформа отберёт первые десять записей из тех, что доступны пользователю.

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

Когда в запросе указано РАЗРЕШЕННЫЕ, платформа 1С модифицирует итоговый SQL-запрос к базе данных. К нему добавляются условия, сформированные на основе ролей пользователя и шаблонов ограничения доступа к данным. Если для таблицы настроен RLS (например, менеджер видит только свои заказы), эти условия подставляются в секцию WHERE автоматически.

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

Важно понимать: РАЗРЕШЕННЫЕ не «разрешает» что-то дополнительно. Оно только сужает выборку до доступного объёма. Получить через запрос данные, на которые у пользователя прав нет, это ключевое слово не поможет — для этого существуют привилегированные модули.

Синтаксис и варианты написания

Ключевое слово ставится первым после ВЫБРАТЬ и до указания ПЕРВЫЕ n. Порядок строго фиксирован: ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 100 .... Обратная последовательность вызовет синтаксическую ошибку при проверке запроса.

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

Пример типового запроса с отбором доступных документов:

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

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

Когда использовать РАЗРЕШЕННЫЕ, а когда нет

Применяйте РАЗРЕШЕННЫЕ везде, где результат запроса попадает пользователю напрямую: динамические списки, отчёты на СКД, обработки подбора, произвольные выборки в формах. Это гарантирует, что сотрудник не увидит лишнего, даже если откроет отчёт с «хитрыми» отборами.

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

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

РАЗРЕШЕННЫЕ или привилегированный режим

РАЗРЕШЕННЫЕ

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

Привилегированный режим

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

Запрос без РАЗРЕШЕННЫЕ в обычном режиме

Допустим, только если RLS в системе не используется и права на объект есть у всех. Иначе риск ошибки доступа или утечки данных.

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

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

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

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

Типичные ошибки при работе с РАЗРЕШЕННЫЕ

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

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

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

Как проверить, что ограничения работают

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

Для динамических списков проверьте свойство «Произвольный запрос» и текст основного запроса: если список должен учитывать права, РАЗРЕШЕННЫЕ должно присутствовать. В отчётах на СКД платформа может добавлять ограничения автоматически, но при ручном редактировании текста запроса набора данных контроль остаётся на разработчике.

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

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

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

Состав выборки под ограниченным пользователем

Норма

Видны только записи, разрешённые шаблоном RLS

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

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

Время выполнения отчёта

Норма

Приемлемое время, сопоставимое с запросом без ограничений

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

Кратное замедление — проверяйте шаблоны RLS и план запроса

Работа служебных алгоритмов

Норма

Проведение и расчёты используют полные данные в привилегированном режиме

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

В служебных запросах стоит РАЗРЕШЕННЫЕ — итоги расходятся

Частые вопросы

Чем РАЗРЕШЕННЫЕ отличается от обычного ГДЕ с отбором по организации?

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

Почему запрос с РАЗРЕШЕННЫЕ возвращает пустой результат?

Чаще всего у пользователя нет права «Чтение» на сам объект метаданных, либо шаблон RLS отсекает все записи. Проверьте роли пользователя и корректность параметров в шаблоне ограничения — например, заполнен ли у пользователя реквизит, по которому строится ограничение.

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

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

Нужно ли РАЗРЕШЕННЫЕ в каждой части ОБЪЕДИНИТЬ ВСЕ?

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

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

Зависит от шаблонов RLS. При простых ограничениях по одному параметру сеанса замедление незначительно. При сложных шаблонах с соединениями к нескольким справочникам итоговый SQL может вырасти существенно — тогда оптимизируют сам шаблон, а не отказываются от контроля доступа.

Можно ли использовать РАЗРЕШЕННЫЕ в запросах к виртуальным таблицам регистров?

Да, ключевое слово работает и с виртуальными таблицами (Остатки, Обороты, СрезПоследних). Ограничения RLS применяются к итоговой выборке, но помните, что для расчётов по остаткам в служебной логике ограниченная выборка даст неверные итоги.