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