Подробный гайд по отладке RLS в 1С:Предприятие 8.3 - Часть 1

Практический гайд по отладке RLS в 1С:Предприятие 8.3. Разбор ролей, параметров сеанса, БСП, SQL и типичных ошибок доступа.

2026.09.15                  


Подробный гайд по отладке RLS в 1С:Предприятие 8.3 - Часть 1Подробный гайд по отладке RLS в 1С:Предприятие 8.3 - Часть 1

1. Что такое RLS в контексте 1С

RLS, Row-Level Security, в 1С — это ограничение доступа на уровне записей. Пользователь может иметь право читать объект метаданных, но видеть не все записи, а только те, которые разрешены условием ограничения.

Примеры:

  • менеджер видит только свои заказы;
  • пользователь видит документы только по своей организации;
  • кладовщик видит документы только по своему складу;
  • руководитель видит документы подчиненных подразделений;
  • внешний пользователь видит только свои заявки.


В 1С RLS может быть реализован через:

  1. Платформенные ограничения доступа на уровне записей в ролях.
  2. Механизмы БСП: виды доступа, группы доступа, профили групп доступа, значения доступа.
  3. Программные фильтры в запросах, формах, отчетах.
  4. Комбинацию всех перечисленных механизмов.

При отладке первое, что нужно сделать, — понять, какой именно слой ограничивает данные.


2. Типовые симптомы проблем с RLS

Проблемы обычно выглядят так:

2.1. Пользователь не видит часть записей

Например, в списке документов пусто или отсутствуют документы, которые пользователь должен видеть.

Возможные причины:

  • неправильно заполнены параметры сеанса;
  • условие RLS слишком жесткое;
  • пользователь не входит в нужную группу доступа;
  • в БСП не настроены значения доступа;
  • запрос не использует ограничения прав доступа;
  • запись не соответствует ни одному условию доступа.

2.2. Пользователь видит лишнее

Например, пользователь видит документы чужой организации или чужого склада.

Возможные причины:

  • пользователю назначена роль с полными правами;
  • одна из ролей дает неограниченное чтение;
  • в БСП профиль доступа разрешает все объекты;
  • запрос не применяет РАЗРЕШЕННЫЕ;
  • отчет или обработка читают данные в привилегированном режиме;
  • временные таблицы заполняются без учета прав.

2.3. Пользователь видит запись в списке, но не может открыть

Возможные причины:

  • есть ограничение на чтение, но нет прав на просмотр или изменение;
  • форма при открытии читает связанные данные, к которым нет доступа;
  • отсутствует право на реквизит или связанную таблицу;
  • ограничение срабатывает только на изменение, а не на чтение;
  • открытие объекта выполняется через другой механизм доступа.

2.4. Пользователь не может записать документ

Возможные причины:

  • нет прав на изменение или добавление;
  • ограничение на уровне записей для операции изменения не разрешает запись;
  • при записи читаются регистры или связанные объекты без прав;
  • код модуля использует привилегированный режим некорректно;
  • БСП запрещает изменение из-за настроек профиля или группы доступа.

2.5. Все работает медленно

RLS может сильно влиять на производительность.

Типовые причины:

  • условие содержит большие списки значений;
  • ограничение приводит к сложным соединениям;
  • поля в условии не проиндексированы;
  • условие не может быть эффективно передано в СУБД;
  • используется много ролей или много параметров;
  • БСП рассчитывает значения доступа динамически и тяжело.

3. Подготовка к отладке

3.1. Не отлаживайте сразу в продуктивной базе

Желательно подготовить копию базы или тестовый контур. Причины:

  • RLS связан с безопасностью;
  • можно случайно дать лишние права;
  • можно неверно изменить роли или группы доступа;
  • диагностика производительности может создать нагрузку.

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


3.2. Создайте воспроизводимый сценарий

Для диагностики нужно иметь минимальный набор данных:

  1. Конкретный пользователь.
  2. Конкретная роль, профиль доступа или группа доступа.
  3. Конкретный объект метаданных: документ, справочник, регистр.
  4. Конкретная запись, которая должна быть видна.
  5. Конкретная запись, которая должна быть не видна.
  6. Операция: чтение, изменение, удаление, просмотр в форме, чтение через запрос.

Пример:

Пользователь manager1 должен видеть документ ЗаказКлиента с менеджером manager1, но не должен видеть документ с менеджером manager2. Если сценарий не воспроизводится точно, отладка превращается в поиск случайных совпадений.




3.3. Подготовьте тестового пользователя

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

Важно:

  • не используйте администратора для проверки RLS;
  • не назначайте тестовому пользователю роль с полными правами;
  • проверьте, что пользователь действительно входит в нужные группы;
  • если используется БСП, проверьте группы и профили доступа;
  • если используется доменная аутентификация, проверьте соответствие пользователя ИБ и пользователя ОС.

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


3.4. Определите слой ограничения

Перед тем как лезть в роли, запросы и БСП, ответьте на вопрос:

  • Где именно должна ограничиваться видимость?

Варианты:

  1. Платформенная роль с ограничением на уровне записей.
  2. БСП: виды доступа, группы доступа, значения доступа.
  3. Программный фильтр в запросе.
  4. Фильтр в форме списка.
  5. Фильтр в отчете СКД.
  6. Внешний сервис, веб-сервис или HTTP-сервис.

Если в конфигурации используется БСП, очень часто проблема не в платформенной роли, а в настройках групп доступа.


4. Проверка ролей и прав пользователя

4.1. Проверьте состав ролей пользователя

Откройте карточку пользователя и проверьте:

  • активен ли пользователь;
  • назначены ли роли;
  • нет ли роли с полными правами;
  • нет ли лишних ролей;
  • не перекрывают ли роли друг друга.

Особенно важно:

Если у пользователя есть роль, дающая право чтения объекта без ограничений, она может привести к тому, что пользователь будет видеть больше, чем ожидалось. Для диагностики лучше всего временно оставить пользователю одну тестовую роль.


4.2. Проверьте права на объект

Для объекта метаданных у пользователя должны быть нужные права.

Например, для чтения документа обычно нужно право:

  • Чтение;
  • иногда также Просмотр, если объект открывается в форме.

Для изменения:

  • Изменение;
  • иногда Чтение, Просмотр, Редактирование в зависимости от механизма.

Для удаления:

  • Удаление.

Если у пользователя нет базового права на объект, RLS уже не имеет значения — объект будет недоступен полностью.


4.3. Проверьте, не слишком ли широкие права

Частая ошибка:

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

Проверьте:

  • роли пользователя;
  • профили групп доступа;
  • группы пользователей;
  • наследование ролей;
  • расширения, если они добавляют роли.

4.4. Проверьте роли в расширениях

Если используются расширения:

  1. Проверьте, активно ли расширение.
  2. Проверьте, назначены ли роли из расширения.
  3. Проверьте, не переопределяют ли они основную конфигурацию.
  4. Проверьте безопасный режим расширения, если он используется.
  5. Убедитесь, что изменение конфигурации принято и опубликовано.

Иногда кажется, что роль изменена в основной конфигурации, но фактически применяется роль из расширения.


5. Проверка платформенных ограничений на уровне записей

5.1. Где искать ограничения

Обычно ограничения на уровне записей настраиваются в роли:

  • открывается роль;
  • выбирается объект метаданных;
  • для операции чтения, изменения или удаления задается условие ограничения.

В зависимости от версии платформы и конфигурации это может называться:

  • ограничения доступа на уровне записей;
  • RLS;
  • шаблоны ограничений;
  • условия ограничения.

5.2. Проверьте, для какой операции задано ограничение

Ограничение может быть задано отдельно для разных операций.



Например:

  • только для чтения;
  • для чтения и изменения;
  • для удаления;
  • для добавления, если механизм это поддерживает.

Частая ошибка:

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

Или наоборот:

Пользователь видит документ в списке, но не может изменить, потому что ограничение на изменение другое или отсутствует нужное право.


5.3. Проверьте текст условия

Условие ограничения обычно похоже на выражение запроса.

Примеры:

Менеджер = &ТекущийМенеджер
Организация = &РазрешеннаяОрганизация
Склад В (&РазрешенныеСклады)
Подразделение В (&РазрешенныеПодразделения)
ИЛИ Автор = &ТекущийПользователь

Проверьте:

  1. Правильное имя реквизита.
  2. Правильный оператор: =, В, НЕ В, И, ИЛИ, НЕ.
  3. Правильные параметры сеанса.
  4. Корректность скобок.
  5. Нет ли опечаток.
  6. Не используется ли условие, которое всегда ложно.
  7. Не используется ли условие, которое всегда истинно.

5.4. Проверьте параметры сеанса

RLS очень часто использует параметры сеанса.

Например:

Организация = &МояОрганизация

Если параметр МояОрганизация не заполнен или заполнен неверно, пользователь не увидит нужные записи.

Проверьте:

  1. Существует ли параметр сеанса в конфигурации.
  2. Заполняется ли он при старте сеанса.
  3. Какой у него тип.
  4. Какое значение он получил для конкретного пользователя.
  5. Не пустое ли значение.
  6. Совпадает ли тип значения параметра с типом реквизита в условии.

6. Диагностика параметров сеанса

6.1. Где задаются параметры сеанса

Параметры сеанса обычно задаются в обработчике:

ПриОпределенииПараметровСеанса

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

Пример:

Процедура ПриОпределенииПараметровСеанса(ПараметрыСеанса) Экспорт

    ПараметрыСеанса.РазрешеннаяОрганизация = ПолучитьОрганизациюПользователя();

КонецПроцедуры

В типовых конфигурациях и БСП заполнение параметров может быть значительно сложнее.

Там могут использоваться:

  • общие модули;
  • подписки на события;
  • справочники пользователей;
  • значения доступа;
  • регистры сведений;
  • временные таблицы;
  • кэширование.

6.2. Проверка значения параметра

Создайте серверную процедуру, которая запишет значение параметра в журнал регистрации.

Пример:

&НаСервере
Процедура Отладка_ЗаписатьПараметрыСеанса()

    Текст = "Текущий пользователь ИБ: "
        + Строка(ПользователиИнформационнойБазы.ТекущийПользователь())
        + "; Параметр сеанса РазрешеннаяОрганизация: "
        + Строка(ПараметрыСеанса.РазрешеннаяОрганизация);

    ЗаписьЖурналаРегистрации(
        "ОтладкаRLS",
        УровеньЖурналаРегистрации.Информация,
        ,
        Текст
    );

КонецПроцедуры

Вызовите ее из формы под исследуемым пользователем. Затем откройте журнал регистрации и посмотрите, какое значение параметра реально получил сеанс.


6.3. Проверка типа параметра

Если параметр должен быть ссылкой на справочник, проверьте тип.

Пример:

ЗначениеПараметра = ПараметрыСеанса.РазрешеннаяОрганизация;

Если ТипЗнч(ЗначениеПараметра) <> Тип("СправочникСсылка.Организации") Тогда
    ЗаписьЖурналаРегистрации(
        "ОтладкаRLS",
        УровеньЖурналаРегистрации.Ошибка,
        ,
        "Неверный тип параметра: " + Строка(ТипЗнч(ЗначениеПараметра))
    );
КонецЕсли;

Частая ошибка:

Реквизит в документе имеет тип СправочникСсылка.Организации, а параметр сеанса заполнен строкой, числом или неопределенным значением. В результате условие либо не выполняется, либо работает не так, как ожидалось.




6.4. Пустые значения параметров

Если параметр пустой, условие вида:

Организация = &МояОрганизация

может не вернуть ни одной записи. Иногда это ожидаемое поведение. Иногда ошибка.

Проверьте:

  • должен ли пользователь вообще иметь доступ, если параметр пуст;
  • что считать пустым значением: Неопределено, пустую ссылку, пустой массив;
  • нужно ли подставлять значение по умолчанию;
  • нужно ли запрещать работу при пустом параметре.

6.5. Параметры сеанса и кэш

Параметры сеанса могут определяться при старте сеанса. Если вы изменили механизм заполнения параметров, но пользователь остался в старом сеансе, изменения могут не примениться.

Сделайте:

  1. Завершение сеанса пользователя.
  2. Повторный вход.
  3. При необходимости перезапуск рабочих процессов 1С.
  4. Очистку пользовательского кэша, если проблема связана с клиентским кэшированием.

7. Проверка через запросы

7.1. Используйте консоль запросов

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

7.2. Запрос с ключевым словом РАЗРЕШЕННЫЕ

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

Пример:

Запрос = Новый Запрос;

Запрос.Текст =
"ВЫБРАТЬ
|   КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
|   Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ";

Результат = Запрос.Выполнить();

Выборка = Результат.Выбрать();
Выборка.Следующий();

Сообщить("Количество доступных заказов: " + Выборка.Всего);

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


7.3. Сравнение запроса с РАЗРЕШЕННЫЕ и без него

Для диагностики можно выполнить два запроса:

  1. С РАЗРЕШЕННЫЕ.
  2. Без РАЗРЕШЕННЫЕ.

Пример:

ТекстСРазрешенными =
"ВЫБРАТЬ
|   КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
|   Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ";

ТекстБезРазрешенных =
"ВЫБРАТЬ
|   КОЛИЧЕСТВО(Заказ.Ссылка) КАК Всего
|ИЗ
|   Документ.ЗаказКлиента КАК Заказ";

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

Но будьте осторожны:

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

7.4. Проверка конкретной записи через ПравоДоступа

Для проверки доступа к конкретной записи можно использовать функцию ПравоДоступа.

Пример:

СсылкаНаДокумент = Документы.ЗаказКлиента.НайтиПоНомеру("0000001", );

Если ЗначениеЗаполнено(СсылкаНаДокумент) Тогда

    Сообщить("Чтение: " + ПравоДоступа("Чтение", СсылкаНаДокумент));
    Сообщить("Изменение: " + ПравоДоступа("Изменение", СсылкаНаДокумент));

КонецЕсли;

Это удобно, когда нужно быстро проверить одну запись. Если ПравоДоступа("Чтение", ...) возвращает Ложь, значит пользователь не имеет права читать эту запись с учетом текущих ограничений.


7.5. Проверка через временные таблицы

Частая ошибка:

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

Неправильная логика:

1. Выгрузить все документы во временную таблицу.
2. Показать пользователю временную таблицу.

Правильная логика:

1. Выгрузить только разрешенные документы.
2. Использовать их дальше.


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


8. Проверка списков и форм

8.1. Динамические списки

Если проблема проявляется в списке документа, проверьте:

  1. Используется ли динамический список.
  2. Есть ли у списка собственные отборы.
  3. Есть ли пользовательские настройки, скрывающие записи.
  4. Применяются ли права доступа к источнику данных списка.
  5. Не установлен ли фильтр по организации, складу, пользователю.
  6. Нет ли программного фильтра в модуле формы.

Иногда кажется, что виноват RLS, а на самом деле в списке стоит пользовательский отбор.


8.2. Форма объекта

Если запись видна в списке, но не открывается в форме:

  1. Проверьте ПравоДоступа("Чтение", Ссылка).
  2. Проверьте права на просмотр.
  3. Проверьте права на изменение, если форма открывается в режиме редактирования.
  4. Проверьте, какие данные читает форма при открытии.
  5. Проверьте модуль формы: нет ли чтения связанных объектов без прав.
  6. Проверьте привилегированный режим.

Форма может читать:

  • сам документ;
  • реквизиты;
  • табличную часть;
  • движения;
  • регистры;
  • связанные справочники;
  • настройки пользователя;
  • права на изменение.

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


8.3. Ошибки при открытии формы

Типовые сообщения могут быть похожи на:

  • недостаточно прав;
  • ошибка доступа;
  • нарушение прав доступа;
  • объект не найден;
  • не удалось получить данные.

Если объект не найден, это не всегда означает, что его физически нет. Иногда система скрывает недоступные записи как несуществующие.


9. Проверка отчетов и СКД

9.1. Отчеты могут не учитывать RLS автоматически

Отчет на СКД может читать данные по-разному:

  1. Через запрос с РАЗРЕШЕННЫЕ.
  2. Через запрос без РАЗРЕШЕННЫЕ.
  3. Через временные таблицы.
  4. Через программную выгрузку.
  5. через веб-сервис или внешний источник.

Если отчет показывает лишнее, проверьте текст запроса набора данных.


9.2. Что проверять в отчете

Проверьте:

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

9.3. Пример запроса отчета с учетом разрешений

ВЫБРАТЬ
    Заказ.Дата КАК Дата,
    Заказ.Номер КАК Номер,
    Заказ.СуммаДокумента КАК Сумма
ИЗ
    Документ.ЗаказКлиента РАЗРЕШЕННЫЕ КАК Заказ
ГДЕ
    Заказ.ПометкаУдаления = ЛОЖЬ

Если вместо этого в отчете написано:

ИЗ Документ.ЗаказКлиента КАК Заказ

то ограничения могут не применяться.


10. Особенности отладки в БСП

Во многих типовых конфигурациях используется библиотека стандартных подсистем.

Там доступ часто управляется через:

  • пользователей;
  • группы пользователей;
  • группы доступа;
  • профили групп доступа;
  • виды доступа;
  • значения доступа;
  • настройки прав;
  • параметры сеанса.

В таком случае недостаточно смотреть только платформенные роли.


10.1. Что проверить в БСП

Обычно нужно проверить:

  1. Пользователь включен в нужную группу пользователей или группу доступа.
  2. Для группы доступа назначен нужный профиль.
  3. Профиль не имеет флага полного доступа.
  4. В профиле настроены виды доступа.
  5. Для видов доступа заданы разрешенные значения.
  6. Значения доступа активны.
  7. Нет конфликтующих групп.
  8. Нет наследования более широких прав.
  9. Для объекта включен нужный вид доступа.
  10. Параметры сеанса заполняются по настройкам БСП.

10.2. Типовые места настройки

В зависимости от конфигурации это может находиться в разделах:



  • Администрирование;
  • Настройки пользователя и права;
  • Пользователи и права;
  • Группы доступа;
  • Профили групп доступа;
  • Виды доступа;
  • Значения доступа.

Названия могут отличаться, но смысл обычно одинаковый.


10.3. Типовая ошибка БСП

Пример:

  • пользователь входит в группу Менеджеры;
  • для группы настроен доступ только по организации Организация 1;
  • но пользователь также входит в группу Администраторы или профиль с полным доступом;
  • в результате пользователь видит все.

Или обратная ситуация:

  • пользователю назначили вид доступа по складам;
  • но забыли назначить конкретный склад;
  • пользователь не видит ни одного склада.

10.4. Используйте стандартные отчеты по правам

Во многих конфигурациях есть отчеты или обработки вида:

  • права доступа;
  • настройки прав;
  • группы доступа;
  • полномочия пользователя;
  • анализ прав доступа.

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


Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно.


Статью подготовил: Аверко Денис Сергеевич @Nymexis г. Омск (специалист по ЗИ)

Комментарии

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