Вопрос корректной настройки прав доступа и ограничений на уровне записей (RLS) является одним из самых трудоемких в практике разработчика 1С. Часто мы сталкиваемся с ситуацией, когда конфигурация готова к обновлению, но мы не можем быть на 100% уверены, что рядовой пользователь не поймает ошибку "Недостаточно прав" в самый неподходящий момент. Проблема усугубляется, если в базе работают тысячи сотрудников с разными должностными обязанностями. В этой статье мы подробно разберем, как проактивно искать ошибки в ролевой модели и RLS, не дожидаясь жалоб от пользователей.
Рассмотрим самый надежный способ проверки — имитацию действий пользователя. Если пользователей тысячи, ручная проверка невозможна. Здесь на помощь приходят дымовые тесты. Суть метода заключается в написании простого кода, который под разными учетными записями пытается выполнить базовые действия: открыть форму списка, открыть форму объекта, записать документ.
Для реализации такого подхода часто используют фреймворки типа xUnitFor1C или встроенные возможности тестирования. Мы можем программно перебирать все метаданные и пробовать открывать их под конкретными профилями доступа. Разберем пример логики такого теста:
// Пример логики дымового теста для проверки прав доступа
Для Каждого ДокументМетаданные Из Метаданные.Документы Цикл
Попытка
Форма = Документы[ДокументМетаданные.Имя].ПолучитьФормуСписка();
// Если форма открылась без исключения, права на чтение/просмотр есть
Исключение
ЗаписатьЛогОшибок("Ошибка доступа к списку: " + ДокументМетаданные.Имя + " - " + ОписаниеОшибки());
КонецПопытки;
КонецЦикла;
Такой подход позволяет еще на этапе разработки в тестовой базе выявить объекты, к которым забыли дать доступ или на которых "криво" отработал RLS.
Если ваша конфигурация построена на БСП (что верно для большинства современных решений), проанализируем встроенные инструменты. В составе БСП есть специализированные обработки для разработчиков. Одной из самых полезных является ПроверкаВнедрения.
Эта обработка позволяет проверить:
Также важно помнить, что в современном "Производительном RLS" права кэшируются в специальных регистрах сведений (например, группы "Ключи доступа..."). Рассмотрим ситуацию, когда права настроены верно, но данных пользователь не видит. В этом случае мы должны проверить актуальность данных в регистрах БСП. Для этого используем регламентное задание ОбновлениеКлючейДоступа или специализированную обработку из состава БСП для ручного обновления этих данных.
Выясним причину ошибок еще до запуска кода. Использование Автоматизированной проверки конфигураций (АПК) позволяет выявить нарушения стандартов разработки 1С. АПК проверяет настройки ролей и может указать на потенциально опасные места в запросах RLS. Например, если в ограничении используются поля, на которые у пользователя нет прав доступа, АПК подсветит это как ошибку.
Проанализируем возможности 1C:EDT (Enterprise Development Tool). В отличие от стандартного конфигуратора, EDT проверяет синтаксис текста RLS "на лету". Если вы допустите опечатку в имени поля или функции в тексте ограничения, среда разработки сразу выдаст предупреждение. Также для более глубокого анализа рекомендуется использовать плагины статического анализа (например, SonarQube), которые могут находить избыточные или конфликтующие условия в ролях.
Посмотрим на ситуацию со стороны сервера СУБД. Когда пользователь открывает список, платформа 1С трансформирует запрос с учетом RLS в SQL-запрос. Если мы настроим сбор Технологического журнала с событиями DBMSSQL (или SDBL), мы увидим реальный текст запроса с добавленным условием WHERE.
Это самый мощный метод отладки RLS. Если мы видим, что в SQL-запросе добавилось условие, которое всегда возвращает FALSE (например, WHERE 1=0), значит, платформа определила, что у пользователя нет прав ни на одну запись этой таблицы. Разберем фрагмент настройки logcfg.xml для отлова таких ситуаций:
<event query="DBMSSQL">
<condition>
<eq property="UserName" value="ПроблемныйПользователь"/>
</condition>
</event>
Проанализировав полученный лог, мы сможем точно сказать, какой параметр сеанса или какое значение в условии RLS привело к "отрезанию" данных.
Рассмотрим использование инструментов от сторонних разработчиков, таких как "Инструменты разработчика" (ИР). В консоли запросов ИР есть уникальная возможность выполнить запрос с включенными ограничениями RLS, оставаясь под полными правами, или имитировать контекст другого пользователя. Это позволяет мгновенно проверить, почему конкретный запрос не возвращает данные для определенного сотрудника, не требуя постоянного перезахода в систему под разными логинами.
Также стоит обратить внимание на ключевое слово РАЗРЕШЕННЫЕ. Часто ошибка "Недостаточно прав" возникает в коде, когда разработчик забывает добавить это слово в запрос. Система пытается прочитать все записи таблицы, натыкается на ту, к которой RLS закрыл доступ, и выбрасывает исключение. Рекомендуем провести глобальный поиск по строке НОВЫЙ Запрос и убедиться, что во всех местах, где запрос выполняется в контексте обычного пользователя, присутствует РАЗРЕШЕННЫЕ.
В типовых конфигурациях (ERP, УТ 11, КА) существует встроенный отчет "Права доступа". Мы можем открыть его из карточки пользователя или через раздел администрирования. Этот отчет позволяет наглядно увидеть "слоеный пирог" прав. Если пользователю назначено несколько ролей, отчет покажет суммарное право на объект и, что самое важное, расшифрует, какое именно ограничение RLS действует на чтение или изменение. Это позволяет быстро найти конфликтующие роли, где одна роль разрешает доступ, а ограничение RLS в другой роли (настроенное по "И") его блокирует.
Резюмируем: поиск ошибок в RLS — это комплексная задача. Для быстрой проверки используйте встроенные отчеты БСП и консоли с имитацией прав. Для предотвращения ошибок в будущем — внедрите дымовые тесты и настройте статический анализ кода через АПК или EDT. А в самых сложных случаях, когда логика прав кажется необъяснимой, всегда обращайтесь к анализу Технологического журнала.