Ограничение доступа на уровне записей (RLS) в 1С 8.3
Содержание
RLS (ограничение доступа на уровне записей) в 1С настраивают на двух уровнях: в пользовательском режиме — через профили и группы доступа, и в Конфигураторе — через условия на права роли. Частое заблуждение: чтобы закрыть данные, достаточно снять у роли право «Чтение». Это прячет объект целиком. RLS нужен в другом случае — когда одному пользователю из всего справочника или документа должна быть видна только часть строк: своя организация, свой склад, свои контрагенты.
Чтобы настроить RLS в типовой конфигурации на БСП, его сначала включают флажком в разделе Администрирование → Настройки пользователей и прав, а затем раздают разрешённые значения в группах доступа. В самописном решении условия ограничения пишут вручную в свойствах роли в Конфигураторе. Разберём оба пути с конкретными путями меню, примерами условий и проверкой результата.
Два механизма: платформенный RLS и группы доступа БСП
На платформе 8.3 ограничение на уровне записей — это текст условия, который платформа дописывает к каждому запросу к таблице. Если условие не выполняется для строки, пользователь её не видит и не может изменить. Условие задаётся в роли, отдельно для каждого права.
Поверх этого механизма в типовых конфигурациях (Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11, ERP) работает надстройка из Библиотеки стандартных подсистем — группы и профили доступа. Администратор не пишет код: он отмечает галочками, какие организации, склады или подразделения доступны группе пользователей, а БСП сама формирует условия RLS.
Если у вас типовая конфигурация, почти всегда достаточно настроек в пользовательском режиме. Лезть в Конфигуратор и писать условия роли приходится только в самописных решениях или когда типовых разрезов доступа не хватает.
Что подготовить до включения ограничений
RLS встраивается в права ролей, поэтому сначала должна быть выстроена ролевая модель. Беспорядок в ролях ограничением записей не лечится.
Что должно быть готово:
- роли выстроены, понятно, кто в какую группу доступа входит;
- выбран разрез ограничения — по организации, складу, подразделению или ответственному;
- у администратора остаётся роль с полными правами без ограничений, чтобы не закрыть доступ самому себе;
- сделана резервная копия базы ;
- в клиент-серверной базе есть окно, когда можно попросить пользователей перезайти.
Ключевые моменты подготовки:
- 🎯 Один разрез на старте. Начните с одного измерения доступа (например, по организации). Несколько разрезов одновременно резко усложняют отладку и тормозят базу.
- 🔑 Роль администратора вне ограничений. У пользователя с полными правами RLS обычно не действует — иначе при ошибке в условии вы потеряете доступ ко всей базе.
- 🧩 Реквизит, по которому режем, должен быть заполнен. Если у части документов не указана организация или ответственный, после включения RLS они просто пропадут из списков.
Перед включением ограничения сделайте резервную копию базы. Ошибка в условии способна скрыть данные у всех пользователей сразу, и откат к копии — самый быстрый способ вернуть работу.
Включение и настройка через профили групп доступа
Это основной путь для типовых конфигураций. Код писать не нужно.
Шаг 1. Включите ограничение. Откройте Администрирование → Настройки пользователей и прав. Найдите группу настроек, относящуюся к ограничению доступа, и установите флажок Ограничивать доступ на уровне записей (название группы в вашем релизе может отличаться, но флажок именно про уровень записей). Без этого флажка настройки ниже не действуют.
Шаг 2. Проверьте профили групп доступа. Там же перейдите в Профили групп доступа. Профиль — это набор ролей плюс перечень разрезов, по которым можно ограничивать: виды доступа «Организации», «Склады», «Подразделения» и так далее. В типовых профили уже заданы; при необходимости скопируйте профиль и отредактируйте копию, а не поставляемый оригинал.
Шаг 3. Создайте группу доступа. В Группы доступа добавьте группу, выберите профиль и включите в неё пользователей.
Шаг 4. Раздайте разрешённые значения. В карточке группы доступа на вкладке с ограничениями укажите конкретные значения: какие организации, склады или подразделения видит группа. Пустой список обычно означает «все» — это частый источник путаницы.
После записи изменения вступают в силу для новых сеансов. Пользователю, который уже работает, нужно перезайти в программу.
Условия ограничения в Конфигураторе: как пишутся скрипты RLS
Если конфигурация самописная или типового разреза не хватает, условие задают вручную.
Откройте роль в дереве метаданных, перейдите на закладку Права. Выберите объект (справочник, документ, регистр) и справа, в области Ограничения доступа к данным, добавьте строку. В ней выбирается право (Чтение, Добавление, Изменение, Удаление), поля и текст условия. Ограничение задаётся отдельно для каждого права: разрешив чтение, вы не разрешили изменение автоматически.
Текст условия — это выражение в языке, близком к секции ГДЕ запроса. Платформа подставит его как дополнительный фильтр. Простейший пример — показывать только свои записи:
Ответственный = &ТекущийПользователь
Здесь Ответственный — реквизит таблицы, а &ТекущийПользователь — параметр сеанса. Можно обращаться к связанным полям через точку и использовать операторы В, В ИЕРАРХИИ, И, ИЛИ, НЕ.
Параметры сеанса. Значение &ТекущийПользователь надо откуда-то взять. Параметры сеанса объявляют в ветке метаданных Параметры сеанса, а заполняют в модуле сеанса, в процедуре УстановкаПараметровСеанса. Она срабатывает в начале каждого сеанса:
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
ПараметрыСеанса.ТекущийПользователь = ТекущийПользователь();
КонецПроцедуры
Несколько разрешённых значений. Когда доступна не одна организация, а список, условие строят через оператор В и подзапрос или параметр-коллекцию. Логика та же: платформа оставит строки, у которых значение реквизита попадает в разрешённый набор. Для справочников с группами удобен В ИЕРАРХИИ — он открывает доступ сразу к ветке:
Контрагент.Родитель В ИЕРАРХИИ (&РазрешеннаяГруппаКонтрагентов)
Ограничение на уровне полей. RLS в 1С умеет резать не только строки, но и отдельные поля (колонки). В строке ограничения можно указать конкретные реквизиты: тогда условие применится к доступу именно к ним, а не ко всей записи. Это нужно редко — например, спрятать сумму договора, оставив видимым сам факт его существования.
Шаблоны ограничений. Чтобы не дублировать одно и то же условие в десятках объектов, его выносят в шаблон на закладке Шаблоны ограничений роли и подставляют по имени: #ИмяШаблона(Параметры). Именно так устроен RLS в БСП — там применяются стандартные шаблоны вида #ПоЗначениям и #ПоНаборуЗначений, а значения подставляет механизм ключей доступа.
Не усложняйте текст условия. Чем сложнее выражение, тем тяжелее оно ложится в каждый запрос к таблице. Тяжёлую логику выносите в заранее рассчитанные данные (регистр, ключи доступа), а в условии оставляйте простую проверку вхождения.
Типовые сценарии и как их задать
Разрез доступа выбирают по бизнес-смыслу. Чаще всего встречаются такие сценарии.
| Задача | Разрез | Где настроить |
|---|---|---|
| Менеджер видит документы только своей организации | По организации | Вид доступа «Организации» в группе доступа |
| Кладовщик работает только со своим складом | По складу | Вид доступа «Склады» |
| Руководитель подразделения видит своих сотрудников | По подразделению | Вид доступа «Подразделения» |
| Пользователь видит только свои документы | По ответственному | Условие Ответственный = &ТекущийПользователь |
| Доступ к группе контрагентов | По группе справочника | Условие с оператором В ИЕРАРХИИ |
Несколько разрезов можно комбинировать (например, своя организация И свой склад), но каждый добавленный разрез — это ещё одно условие в запросах и ещё один повод для медленных списков. Добавляйте их по одному и проверяйте скорость работы после каждого.
Отдельный момент — фоновые задания и регламентные операции. Они выполняются в привилегированном режиме, где RLS не действует. Это нормально: закрытие месяца или обмен данными должны видеть все строки. Но если вы рассчитываете на то, что RLS спрячет данные и в фоновой обработке, — так это не работает .
Как проверить, что ограничение работает
Проверять RLS из-под администратора бессмысленно: у него ограничений нет. Нужен тестовый пользователь.
- Заведите тестового пользователя и включите его в настроенную группу доступа.
- Раздайте ему разрешённые значения (например, одну организацию из трёх).
- Запустите 1С:Предприятие под этим пользователем в отдельном сеансе.
- Откройте список документов и убедитесь, что видны только строки по разрешённой организации.
- Попробуйте открыть «чужой» документ по прямой ссылке — должно появиться сообщение о нарушении прав доступа, а не просто пустой список.
Для разработчика в Конфигураторе есть режим отладки под конкретным пользователем: запуск 1С:Предприятия из Конфигуратора позволяет задать имя пользователя, под которым стартует сеанс. Так удобно проверять условие, не выходя из среды разработки.
Что именно отсекает RLS, помогает понять журнал регистрации: события доступа и отказов фиксируются там. Если список неожиданно пуст, сначала проверьте, заполнен ли у документов реквизит, по которому вы режете доступ.
Производительность и частые ошибки
RLS дорого обходится базе: условие добавляется в каждый запрос к таблице, включая построение списков и отчётов. На больших объёмах неаккуратное условие превращает открытие журнала документов в многосекундное ожидание.
УстановкаПараметровСеанса модуля сеанса. Добавьте присвоение значения параметру.Ещё несколько ловушек, которые стоит держать в голове:
- 🔁 Ограничение на чтение не равно ограничению на изменение. Если вы закрыли чтение, но забыли про изменение, пользователь может не видеть документ в списке, но провести его по прямой ссылке.
- 🧮 Пустой список разрешённых значений = доступ ко всему. Это поведение по умолчанию во многих профилях, и его легко принять за «доступ закрыт».
- 🧊 RLS не заменяет общие права. Если у роли вообще нет права «Изменение» на объект, никакое условие записей его не добавит.