При разработке собственных конфигураций на базе 1С:Предприятие 8.3 часто возникает задача внедрения системы разграничения прав доступа на уровне записей (RLS — Record Level Security). Использование подсистемы «Управление доступом» из состава Библиотеки стандартных подсистем (БСП) значительно упрощает эту задачу, но требует соблюдения строгой последовательности действий. Рассмотрим ситуацию, когда для самописного документа ограничение по организации успешно работает на чтение (в списках), но позволяет выбирать любые организации при создании или изменении документа.
Проанализируем основную причину, по которой ограничения могут «игнорироваться» системой. В платформе 1С:Предприятие права, предоставляемые пользователю различными ролями, всегда суммируются по принципу логического «ИЛИ». Это означает, что если у пользователя есть три профиля («Деньги», «Продажи» и «Самописный»), и хотя бы в одном из них (например, в «Деньгах») разрешен доступ ко всем организациям без ограничений RLS, то это разрешение перекроет любые ограничения, установленные в «Самописном» профиле.
Выясним причину такого поведения в контексте списков выбора. Если пользователь открывает поле выбора организации в вашем документе, система проверяет права на справочник Организации. Если в других ролях справочник Организации доступен на чтение без условий RLS, пользователь увидит в выпадающем списке все элементы. Для корректной работы ограничения должны быть наложены на все роли, дающие доступ к объекту или связанным справочникам.
Для того чтобы подсистема БСП «увидела» ваш документ и начала обрабатывать его ключи доступа, необходимо включить его в состав нескольких определяемых типов. Без этого стандартные подписки на события не будут срабатывать. Рассмотрим список необходимых типов:
Проанализируем настройку самой роли. В БСП для реализации RLS используются стандартные шаблоны, такие как #ПоЗначениям. Важно понимать, что текст ограничения для прав «Чтение», «Добавление» и «Изменение» может быть одинаковым, но механизмы их работы различаются.
Посмотрим на пример стандартного шаблона в роли:
#ПоЗначениям("Документ.НашСамописныйДокумент", "", "", "Организации", "Организация", "", "", "", "", "", "", "", "")
Если этот текст прописан в правах на чтение, он будет фильтровать список документов. Если он прописан в правах на изменение — система не даст записать документ с организацией, на которую у пользователя нет прав. Однако, если пользователю разрешено чтение справочника Организации без RLS в других ролях, он все равно сможет выбрать «чужую» организацию в поле, но получит ошибку «Нарушение прав доступа» только в момент нажатия кнопки «Записать».
Иногда стандартных механизмов RLS на уровне платформы недостаточно для комфортной работы интерфейса. Чтобы гарантировать проверку прав перед записью, убедитесь, что ваш документ участвует в работе подписок ПроверитьДоступПередЗаписьюДокумента и ПроверитьДоступПриЗаписиДокумента. Если требуется жесткая проверка в коде, мы можем вызвать метод программного интерфейса БСП в модуле объекта:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Программная проверка прав доступа через подсистему БСП
УправлениеДоступом.ПроверитьДоступ(ЭтотОбъект);
КонецПроцедуры
Эта проверка гарантирует, что никаким программным способом (через обработки или загрузки) документ с недопустимыми значениями не будет сохранен в базе данных.
После внесения изменений в метаданные или состав ролей, механизмы БСП (особенно в версиях 3.0 и выше) требуют обновления внутренних таблиц — ключей доступа. Рассмотрим последовательность действий:
/С ЗапуститьОбновлениеИнформационнойБазы или через специализированные обработки в составе БСП.Если ограничения все еще работают некорректно, проанализируем ситуацию с помощью встроенного инструмента БСП. В карточке любого документа (или в списке) обычно присутствует кнопка или пункт меню «Права доступа». Откройте этот отчет для конкретного пользователя и проблемного документа.
Важные моменты, на которые стоит обратить внимание в отчете:
Для успешной работы RLS на самописном документе недостаточно просто добавить шаблоны в роль. Необходимо обеспечить целостность ограничений во всех ролях пользователя и правильно интегрировать объект в инфраструктуру БСП через определяемые типы и регламентные задания. Помните: RLS в 1С никогда не запрещает, он только ограничивает область разрешенного. Если какая-то роль разрешила всё — остальные ограничения не имеют смысла.