1C-Code → Основы 1С → Права, роли и RLS
Права, роли и RLS
Кто что может видеть и делать. Роли и их сложение, права на объект и на действие, и построчное ограничение — тема, на которой валятся на собеседовании.
Глава 24 из 36 · чтение примерно 24 минут
Кладовщик не должен видеть зарплату. Менеджер видит только своих клиентов. Бухгалтер проводит документы, а стажёр только смотрит. Всё это — права, и они устроены не так, как обычно думают.
Роль — это набор разрешений
Роль в конфигурации перечисляет, что можно делать с каждым объектом: читать, добавлять, изменять, удалять, проводить.
Пользователю назначают роли — их может быть несколько. И вот главное свойство, которое спрашивают: роли СКЛАДЫВАЮТСЯ. Если в одной роли чтение запрещено, а в другой разрешено, — человек будет читать. Запрета, перебивающего разрешение, в 1С нет.
Отсюда следствие: «отобрать право, добавив роль» невозможно. Лишнее право убирают из той роли, где оно выдано.
Виды прав
| Право | Что означает |
|---|---|
| Чтение | видеть данные объекта |
| Добавление | создавать новые |
| Изменение | править существующие |
| Удаление | удалять окончательно |
| Проведение | проводить документ |
| ИнтерактивноеУдаление | удалять мышью, минуя пометку |
| Просмотр / Использование | видеть команду или отчёт в интерфейсе |
Интерактивное удаление
ИнтерактивноеУдаление — право удалить объект мышью сразу, минуя пометку на удаление и контроль ссылок. Его не дают почти никому, включая администраторов.
Причина: удалённый так объект может быть записан в десятке документов, и они станут ссылаться в пустоту. Правильный путь — пометка удаления и обработка «Удаление помеченных объектов», которая проверяет ссылки.
В типовой роли не назначают
Всё, что написано выше, — про платформу. А в типовой конфигурации на БСП роли пользователю почти никогда не выдают напрямую, и человек, который ищет в 1С:Бухгалтерии галочку «роль Кладовщик», её не находит.
Там стоит слой из трёх понятий, и путать их нельзя.
Роль, профиль, группа доступа
| Что это | Где живёт | Кто заводит |
|---|---|---|
| Роль | конфигурация | разработчик — руками её не создать |
| Профиль группы доступа | данные базы | администратор: набор ролей под одну работу |
| Группа доступа | данные базы | администратор: профиль плюс список людей плюс значения RLS |
| Пользователь | данные базы | входит в одну или несколько групп доступа |
Смысл слоя в том, что администратор настраивает доступ без конфигуратора: он собирает профиль из готовых ролей и говорит в группе доступа «эти люди, эти организации, эти склады». Значения для RLS берутся оттуда же.
Поэтому на боевой базе ответ на «почему он это видит» ищут не в конфигураторе, а в группах доступа. И наоборот: добавили роль в конфигурации — она никому не досталась, пока её не включили в профиль.
RLS: ограничение на уровне записей
Право «читать справочник Контрагенты» — всё или ничего. А нужно бывает «читать только своих».
Для этого есть RLS — ограничение доступа на уровне записей. Это условие, которое платформа дописывает в каждый запрос к объекту. Человек пишет «ВЫБРАТЬ … ИЗ Справочник.Контрагенты», а до базы доходит запрос с добавленным условием «И Ответственный = ТекущийПользователь».
Поэтому RLS нельзя обойти из кода: он не в интерфейсе, он в самом запросе.
RLS: права на строки, а не на таблицу
Роль отвечает на вопрос «можно ли читать справочник контрагентов». RLS отвечает на другой: «каких именно контрагентов можно читать этому человеку».
Устроено это как условие, которое платформа дописывает в каждый запрос к таблице — включая запросы типовых отчётов и списки на формах. Человек не видит отфильтрованных строк нигде и не узнаёт, что они есть.
Пишут условие на языке запросов, а данные для него обычно берут из параметров сеанса: «текущий пользователь», «его организации», «его склады».
RLS стоит дорого
Условие дописывается в КАЖДЫЙ запрос к таблице. Если оно сложное — с соединениями и подзапросами, — то каждый отчёт в базе становится тяжелее ровно на эту сложность.
Поэтому данные для RLS стараются готовить заранее: держат готовый регистр «пользователь → доступные организации» и в условии обращаются к нему одним сравнением.
И второе: под полными правами RLS не применяется вовсе. Поэтому проверять ограничения надо под той самой ролью, а не «у меня всё работает».
Откуда RLS берёт «текущего пользователя»
Условие RLS написано на языке запросов, и подставить в него значение неоткуда — запрос не знает, кто его выполняет. Значение приходит из параметра сеанса.
Параметр сеанса — это переменная, которая живёт от входа до выхода и одинакова для всего сеанса. Заполняют её один раз, при старте, в специальной процедуре модуля сеанса.
Заполнение параметра сеанса
// Модуль сеанса
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
ПараметрыСеанса.ТекущийПользователь = ПользователиКлиентСервер.ТекущийПользователь();
КонецПроцедуры| Часть | Что означает |
|---|---|
Модуль сеанса | выполняется на сервере ДО того, как человек что-то увидит |
ТребуемыеПараметры | Неопределено при первом обращении — значит заполнить надо все |
ПараметрыСеанса.… | дальше это значение подставляется в каждое условие RLS |
без него | параметр пуст, условие RLS не выполняется ни для одной строки — человек видит пустые списки |
Ошибка в модуле сеанса не даёт войти НИКОМУ
Это самый неприятный модуль в конфигурации. Он выполняется раньше всего остального, и если в нём падает ошибка — в базу не входит ни один пользователь, включая администратора.
Спасает запуск конфигуратора: он модуль сеанса не выполняет. Поэтому правило простое — в модуле сеанса пишут минимум, и любое обращение к данным там оборачивают в Попытка.
Второе правило: никаких тяжёлых запросов. Этот код выполняется при каждом входе каждого человека.
У каждого действия — своё условие
RLS задают не «на объект», а на объект и действие: отдельно на чтение, отдельно на добавление, изменение, удаление. И условия у них обычно разные.
Типовая картина: читать менеджер может контрагентов своей организации, а изменять — только тех, где он ответственный. Это два разных условия на одном справочнике.
Забыли условие на изменение — и человек, который видит сто своих контрагентов, может отредактировать любого из тысячи: ограничение на чтение на запись не распространяется.
Условия пишут не с нуля: в конфигурации есть шаблоны ограничений. Шаблон — это кусок условия с параметрами, написанный один раз и вставленный во все роли. Меняется правило — правится шаблон, а не сорок ролей по очереди.
Права, которые забывают дать
Роль — это не только «Чтение» и «Изменение». Права есть у каждого действия, и половина обращений в поддержку — про забытое.
Просмотр — отдельно от чтения: право читать данные кодом есть, а увидеть объект в интерфейсе нельзя.
Проведение и отмена проведения — отдельные права у документа.
Интерактивное удаление, пометка удаления — тоже отдельные, и обычно их не дают никому.
Право на подсистему — без него раздел просто не показывается, и человек говорит «у меня нет кнопки».
Отсюда правило проверки: заходить под ролью, а не гадать по списку галочек.
Привилегированный режим и роли
Код, которому нужно сделать что-то мимо прав пользователя — записать служебный регистр, прочитать настройку, — выполняют в привилегированном режиме, а не расширяют роль.
Разница принципиальная: роль даёт право человеку навсегда, привилегированный режим — коду на три строки. Первое человек может использовать как угодно, второе делает ровно то, что написано.
«Полные права» — это не одна галочка
Три вещи, которые называют словом «админ», и это разные вещи.
Роль «Полные права» — обычная роль конфигурации, в которой отмечены все права. RLS под ней не применяется: условие роли, у которой нет ограничений, не ограничивает ничего.
Право «Администрирование» — управление пользователями, журналом, региональными настройками. Его дают отдельно.
Право «Администрирование данных» — выгрузка и загрузка базы целиком. Это не то же самое, и его обычно не дают никому, кроме одного человека.
Отсюда и любимый ответ разработчика «у меня работает». Работает потому, что он зашёл с полными правами, где RLS выключен и ни одного ограничения нет. Проверять права под полными правами бессмысленно — это проверка того, что ничего не проверяется.
Как проверять права по-настоящему
Зайти этим человеком. Не смотреть галочки, не читать роль — войти в базу под его учётной записью (или под тестовой с тем же профилем) и пройти его работу.
Есть и быстрый способ не выходя из отладки: запустить 1С:Предприятие из конфигуратора, выбрав нужного пользователя. Отладчик при этом работает, и видно, на какой строке приходит «Недостаточно прав».
А сообщение «Недостаточно прав» читают целиком: в нём написано, на какой именно объект и на какое действие прав не хватило. Это ровно та галочка, которую забыли.
На чём спотыкаются
Считают, что RLS «прячет строки в списке». Он их не прячет — их для этого пользователя не существует. Запрос их не вернёт, отчёт не посчитает, и итог будет другой.
Удивляются, что RLS замедляет. Дописанное условие участвует в плане запроса. Сложное ограничение способно превратить быстрый отчёт в медленный, и виновника не видно в тексте запроса — он в роли.
Обходят права привилегированным модулем ради удобства. Привилегированный режим отключает и права, и RLS. Он нужен для узких служебных операций, а не для того, чтобы «не разбираться».
Проверяют права в интерфейсе вместо ролей. Спрятать кнопку — не значит запретить действие: к данным можно обратиться кодом. Прячут ради удобства, запрещают ролью.
Упражнение 1. Роли складываются
Функция МожноЧитать(РольА, РольБ) получает два признака: разрешено ли чтение в первой роли и во второй. Вернуть Истина, если человек сможет читать. Помните: роли складываются, запрет не перебивает разрешение.
Решается в тренажёре: код запускается и проверяется сразу.
Упражнение 2. Почему «у меня нет кнопки»
Чтобы человек увидел справочник в интерфейсе, мало права на чтение. Нужны три вещи сразу: чтение данных, право просмотра и право на подсистему, в которой лежит команда. Функция ВидноВИнтерфейсе(Чтение, Просмотр, Подсистема) должна вернуть Истина, только если есть все три.
Решается в тренажёре: код запускается и проверяется сразу.
Короткий свод
Роль — набор разрешений; ролей у человека несколько, и они складываются: запрета, перебивающего разрешение, не существует. Права бывают на данные и на интерфейс. Интерактивное удаление не дают почти никому. RLS — условие, дописываемое в каждый запрос: его нельзя обойти кодом, но он влияет на скорость. Прятать кнопку — удобство, запрещать — роль.
Как закрепить
Читать про код и писать код — разные умения. В тренажёре к этой главе идут упражнения: вы пишете решение, оно запускается на настоящем интерпретаторе 1С и проверяется сразу, без установки платформы.
← Формы: реквизиты, элементы, события
→ Регистры бухгалтерии и расчёта