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