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