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