Почему не работает ограничение доступа (RLS) в 1С и как это исправить?

Часто в процессе настройки прав доступа в 1С:Управление торговлей 11 возникает ситуация, когда настроенное ограничение доступа на уровне записей (RLS), которое должно ограничивать видимость документов конкретного пользователя, перестает работать. Пользователь начинает видеть документы, к которым у него не должно быть доступа. Разберемся, почему это происходит и как восстановить корректную работу системы.

Принцип работы прав доступа: почему возникает конфликт?

Главная причина, по которой RLS перестает функционировать — это принцип суммирования прав в 1С. Система работает по логике «ИЛИ»: если у пользователя есть несколько ролей, и хотя бы одна из них разрешает полное чтение объекта, ограничение RLS из другой роли будет проигнорировано. Система видит право на чтение документа как «разрешено» и не применяет фильтры безопасности.

Чтобы RLS работал корректно, нужно убедиться, что ни одна другая роль, назначенная пользователю, не дает «безусловных» прав на чтение данных объектов.

Пошаговая диагностика лишних прав

Для того чтобы выявить роль, которая мешает работе RLS, выполним следующие действия:

1. Воспользуемся отчетом по правам: Перейдем в карточку пользователя в режиме «1С:Предприятие» и выберем «Отчет по правам». Этот отчет покажет итоговый список всех прав пользователя и роли, из которых они получены.
2. Проанализируем профили групп доступа: В УТ 11 доступ назначается через группы доступа, которые ссылаются на профили. Проверим, какие профили назначены пользователю. Часто лишние права «прилетают» из стандартных профилей, таких как «Пользователь» или специфических профилей менеджеров.
3. Проверим документ в Конфигураторе: Если отчет не дает полной картины, откроем дерево конфигурации, найдем нужный документ (например, ЗаказКлиента) и посмотрим на колонку «Чтение» у различных ролей. Нам нужно найти те роли, где установлен флаг чтения, помимо той, в которой настроен RLS.

Как правильно исправить ситуацию

После того как мы выявили «виновную» роль, у нас есть несколько стратегий исправления:

Стратегия 1: Создание специализированного профиля

Вместо того чтобы изменять существующие типовые роли (что крайне не рекомендуется, так как это может привести к ошибкам при обновлении конфигурации), создадим новый профиль группы доступа. Назовем его, например, «Менеджер с ограничением». В этот профиль включим только те роли, которые необходимы для работы, исключив те, что дают избыточный доступ на чтение.

Стратегия 2: Удаление лишних групп доступа

Рассмотрим состав групп доступа пользователя. Часто пользователь включен в несколько групп сразу. Разберемся, не дублируют ли они права. Если пользователь состоит в группе, дающей права на просмотр всех заказов компании, RLS не будет работать, пока этот пользователь находится в данной группе.

Пример шаблона ограничения в RLS, который мы хотим сохранить:

ГДЕ Автор = &АвторизованныйПользователь
    ИЛИ Менеджер = &АвторизованныйПользователь
    ИЛИ Партнер.ОсновнойМенеджер = &АвторизованныйПользователь

Важные рекомендации при настройке

При изменении прав всегда помним о следующих правилах:

• Не спешите удалять роли у всех: Всегда работайте с конкретным пользователем или созданной для него группой доступа. Изменение прав на уровне роли в конфигураторе затронет всех пользователей, имеющих эту роль.
• Тестируйте изменения: После удаления роли, которая казалась лишней, обязательно проверим:
  • Видимость самих документов.
  • Возможность проведения документов.
  • Доступность связанных справочников (например, Партнеры, Контрагенты).
  • Работоспособность отчетов, с которыми работает менеджер.
• Используйте профили: Изменяйте состав групп доступа в режиме предприятия, а не путем изменения кода в конфигураторе, если это возможно. Это позволит сохранить целостность типовой конфигурации.

Следуя этим шагам, мы сможем изолировать пользователя в рамках его зоны ответственности, обеспечив корректное применение фильтров RLS и сохранив при этом необходимый функционал для повседневной работы.