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