Доступ на уровне записей в 1С: как развести бухгалтеров по филиалам через БСП-механизм групп доступа
Что такое RLS на самом деле
RLS (Record-Level Security) — это механизм, при котором право пользователя на объект решается не «может — не может» в целом по виду документа, а индивидуально по каждой записи. Один и тот же бухгалтер видит документы реализации своего филиала и не видит документов чужих филиалов, хотя у него одна и та же роль «Бухгалтер».
Где это живёт в типовых конфигурациях
В БП 3.0, УТ 11, ERP 2.x и других конфигурациях, построенных на БСП последних лет, есть подсистема «Управление доступом». Она реализует RLS через комбинацию:
- Профили групп доступа — преднастроенные наборы ролей под бизнес-функцию (Бухгалтер, Менеджер по продажам, Кладовщик и т.п.);
- Группы доступа — конкретные экземпляры профиля с указанием состава пользователей и ограничений;
- Виды доступа — измерения, по которым ограничиваем: Организации, Подразделения, Склады, Контрагенты, Физические лица и др.;
- Группы значений доступа — наборы конкретных значений из видов доступа (например, «Филиал Москва» включает справочники подразделений: «Бухгалтерия Москва», «Продажи Москва»).
Базовый сценарий настройки
Задача: бухгалтер филиала видит только документы своего подразделения. Идём по штатному пути, без программирования. Важный нюанс: профиль «Бухгалтер» в типовых конфигурациях чаще включает вид доступа «Организации», а не «Подразделения» — если вам нужно именно «по подразделениям», сначала убедитесь, что этот вид доступа активен в RLS-шаблонах профиля; иначе потребуется расширение профиля.
| Шаг | Что делаем | Где в интерфейсе |
|---|---|---|
| 1. Включить RLS | Активировать ограничения на уровне записей | НСИ и администрирование (в БП 3.0 — просто «Администрирование») → Настройки пользователей и прав → флажок «Ограничивать доступ на уровне записей» |
| 2. Включить нужные виды доступа | Отметить, по каким разрезам будем ограничивать (Подразделения, Организации, Склады) | Та же страница → раздел «Виды доступа» |
| 3. Найти подходящий профиль | Открыть «Профили групп доступа», найти «Бухгалтер» (или ваш аналог) | НСИ и администрирование (в БП 3.0 — просто «Администрирование») → Настройки пользователей и прав → Профили групп доступа |
| 4. Создать группу доступа для филиала | Создать «Бухгалтеры филиала Москва» на базе профиля «Бухгалтер» | НСИ и администрирование (в БП 3.0 — просто «Администрирование») → Настройки пользователей и прав → Группы доступа → Создать |
| 5. Привязать пользователей | На вкладке «Пользователи» добавить сотрудников филиала | В карточке созданной группы доступа |
| 6. Указать ограничения | На вкладке «Ограничения» в виде доступа «Подразделения» выбрать конкретные подразделения филиала Москва | Там же |
| 7. Проверить под пользователем | Зайти под бухгалтером, открыть «Реализации», убедиться, что виден только свой филиал | Любым клиентом 1С |
После шага 7 — система отрабатывает RLS прозрачно для пользователя: он просто не видит того, чего не должен видеть. На каждой выборке платформа подмешивает условие WHERE с проверкой групп значений доступа.
Если у вас 30 человек в 4 филиалах, нужно 4 группы доступа (а не 30 индивидуальных настроек). Принцип: ограничения накладываются на группу, а не на пользователя. Это масштабируется при добавлении новых сотрудников: вы просто добавляете их в нужную группу, и они автоматически получают правильный срез данных.
Где RLS заметно тормозит
RLS — это дополнительные JOIN и WHERE в каждом запросе, и на больших регистрах это может ощутимо просесть в производительности. Ситуации, в которых нужно особое внимание:
- Регистры накопления с миллионами записей и активной отчётностью — каждый запрос отчёта проходит через проверку доступа.
- Подсистема расчёта зарплаты — там RLS на физлицах накладывает массивные ограничения по всем регистрам начислений.
- Универсальные отчёты и СКД — пользовательские отчёты на больших данных с включённым RLS могут открываться минутами.
Что делать, если тормозит
В подсистеме «Управление доступом» есть стандартные регламентные задания, которые обновляют вспомогательные таблицы наборов и групп значений доступа. Они должны успевать отрабатывать в фоновом режиме. Если они «не успевают» — RLS работает по устаревшим данным и тормозит. Решение — настроить их расписание адекватно нагрузке и запускать вручную после массовых изменений в составе подразделений или пользователей. Точные имена заданий смотрите в «Администрирование → Обслуживание → Регламентные и фоновые задания», фильтр по слову «доступ».
Чек-лист внедрения
- Перед внедрением — соберите матрицу: кто из ролей какие разрезы данных должен видеть. Без матрицы настройка превратится в ad-hoc-чинилку «дайте доступ» через две недели.
- Включите только те виды доступа, которые реально используете — каждый лишний включённый вид доступа замедляет работу платформы.
- Сначала настройте RLS на тестовой копии базы под одним «обкаточным» филиалом — убедитесь, что список Реализаций фильтруется правильно.
- Дайте отработать регламентным заданиям подсистемы «Управление доступом» (фильтр по слову «доступ» в списке регламентных заданий) — без них первая выборка под новым пользователем будет странной.
- Зайдите под каждым типом пользователя — бухгалтер, менеджер, кладовщик — и проверьте отчёты по объектам, к которым у него теоретически нет доступа.
- Документируйте: какая группа доступа какой профиль расширяет и какие ограничения накладывает. Через год вы это сами не вспомните.
Типичные ошибки
- Ограничения на каждого пользователя индивидуально. На 3 пользователей это терпимо. На 30 — это путь к хаосу: половина не видит того, что должна, другая видит лишнее. Ограничения только на группе.
- Включили все виды доступа сразу. Каждый включённый вид доступа — это дополнительная JOIN-обвязка в RLS-запросах платформы. Включайте только то, что реально используете для разделения.
- Забыли запустить регламентные задания. RLS работает «через таблицы-наборы» — без обновления этих таблиц новые пользователи видят либо ничего, либо лишнее.
- «Дать на всякий случай полные права». Роль «Полные права» в типовых на БСП, как правило, обходит ограничения RLS. Прежде чем раздавать её как обходной путь — проверьте поведение в вашей версии БСП. Раздавать её половине пользователей — это всё равно смерть всему механизму разделения.
- Тестирование под Администратором. Финальная проверка обязательно под целевым пользователем, а не под Администратором: под админом RLS, как правило, не применяется, и вы не увидите фактических ограничений.
- Перенос ограничений с продакшена на тест без чистки. Группы доступа с реальными ФИО и подразделениями попадают в тестовую базу — а потом разработчики случайно правят их и переносят обратно. Контур разделять.
Перейти в каталог решений →