Механизм RLS (Record Level Security) в платформе 1С:Предприятие является мощным инструментом разграничения доступа на уровне отдельных записей базы данных. Однако его настройка в нетиповых конфигурациях (где не используется БСП) часто приводит к возникновению ошибки «Недостаточно прав» в моменты, когда пользователь пытается создать новый элемент или изменить существующий, даже если формально права на «Добавление» и «Изменение» у него есть. В этой статье мы подробно разберем причины возникновения этой ситуации и пошагово рассмотрим способы ее решения.
Первое, что нам необходимо осознать: платформа 1С выполняет проверку прав не только «до» начала операции, но и в момент фиксации транзакции. Разберем этот механизм подробнее. Когда пользователь нажимает кнопку «Записать», система проверяет, будет ли этот объект доступен пользователю на «Чтение» сразу после того, как он окажется в базе данных.
Если в вашей роли настроено ограничение на Чтение (например, по группе доступа или менеджеру), а при создании нового контрагента эти поля еще не заполнены или заполнены значениями, не попадающими в фильтр, платформа заблокирует запись. Система «считает», что пользователь пытается создать объект, который он сам же не сможет увидеть после сохранения, что запрещено логикой безопасности.
Рассмотрим пример запроса RLS, который может вызвать ошибку:
ГДЕ Менеджер = &ТекущийПользователь
В данном случае, если в коде или в форме нового контрагента поле Менеджер не заполнено значением текущего пользователя ДО момента фактической записи в БД, возникнет ошибка прав доступа. Проанализируем ситуацию: в базе данных объект еще не существует, поле пустое, пустое поле не равно текущему пользователю — условие Чтение не выполняется — запись отклоняется.
Чтобы избежать этой ошибки, мы должны модифицировать запрос ограничения доступа таким образом, чтобы он разрешал работу с новыми или незаполненными объектами. Разберем по шагам, как дополнить запрос:
Чтение измените текст запроса, добавив проверку на пустое значение или NULL.Пример исправленного запроса:
ГДЕ Менеджер = &ТекущийПользователь
ИЛИ Менеджер = ЗНАЧЕНИЕ(Справочник.Пользователи.ПустаяСсылка)
ИЛИ Менеджер ЕСТЬ NULL
В этом случае система позволит записать объект с незаполненным менеджером, а после его заполнения в коде (например, в событии ПередЗаписью) объект станет окончательно доступен пользователю.
Если ваш справочник контрагентов имеет иерархическую структуру, ситуация усложняется. Выясним причину: для того чтобы пользователь мог записать элемент в определенную группу (папку), он обязан иметь права на Чтение и Просмотр всей цепочки родительских групп, вплоть до корня справочника.
Если ваш RLS скрывает от пользователя группу «Оптовые покупатели», то при попытке программно или интерактивно создать в ней контрагента пользователь получит отказ. Платформа не может поместить объект в контекст, который пользователю недоступен.
Для решения этой задачи проанализируем настройки и убедимся, что:
ЭтоГруппа = Истина, если ограничения должны накладываться только на элементы.Пример запроса, разделяющего логику для групп и элементов:
ГДЕ ЭтоГруппа = ИСТИНА
ИЛИ (ЭтоГруппа = ЛОЖЬ И ОтветственныйМенеджер = &ТекущийПользователь)
Частая ошибка начинающих разработчиков — настройка RLS только для права Чтение. В 1С права Добавление, Изменение и Удаление по умолчанию наследуют ограничения Чтения, если для них не прописаны собственные условия.
Однако, если вы явно разрешили Добавление без ограничений (пустое поле в колонке RLS), но оставили жесткое условие на Чтение, возникнет конфликт, описанный в первом пункте. Система позволит начать транзакцию добавления, но «споткнется» на проверке возможности чтения результата. Мы рекомендуем всегда копировать (или адаптировать) запрос из раздела Чтение в разделы Добавление и Изменение, чтобы логика была прозрачной для платформы.
При записи контрагента в нетиповых конфигурациях часто срабатывают обработчики событий (в модуле объекта или подписки на события), которые пытаются записать данные в другие объекты. Это могут быть:
Проанализируем ситуацию: если у пользователя есть права на справочник Контрагенты, но нет прав (или настроен слишком строгий RLS) на запись в регистр КонтактнаяИнформация, общая транзакция записи контрагента завершится ошибкой «Недостаточно прав». При этом платформа не всегда детально расшифровывает, на какой именно объект не хватило прав.
Как проверить: временно включите «Привилегированный режим» в коде записи или закомментируйте вызовы связанных процедур. Если ошибка исчезнет — ищите проблему в правах доступа к подчиненным объектам.
В конфигурациях, написанных «с нуля», разработчик сам отвечает за инициализацию параметров сеанса, используемых в запросах RLS. Посмотрим на пример: в запросе используется параметр &ДоступныеГруппыКонтрагентов. Если этот параметр не инициализирован в модуле сеанса при запуске или при смене пользователя, он может быть равен NULL или пустому массиву.
В результате запрос RLS вернет «Ложь» для любого объекта, и пользователь не сможет даже создать новую запись, так как она не будет соответствовать условию пустого параметра. Проверьте обработчик УстановкаПараметровСеанса в модуле сеанса и убедитесь, что все переменные, используемые в RLS, заполняются корректно до начала работы пользователя с данными.
Если вы столкнулись с ошибкой прав при работающем RLS, выполните следующие действия:
Чтение на предмет обязательности заполнения полей (используйте ЕСТЬ NULL).Просмотр также активно для данной роли.Журнал регистрации. Часто там фиксируется конкретный объект (метаданные), на который не хватило прав, что значительно сужает область поиска.Следуя этим рекомендациям, мы сможем настроить гибкую и надежную систему безопасности на уровне записей, не блокирующую штатную работу пользователей по созданию новых данных.