Как реализовать разделение прав доступа по подразделениям в 1С:УНФ

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

Анализ стандартных механизмов RLS в 1С:УНФ

Для начала проанализируем штатные возможности системы. В 1С:УНФ реализован механизм RLS (Row Level Security) — это технология ограничения доступа на уровне записей. Она позволяет фильтровать данные в списках документов и справочников в зависимости от прав конкретного пользователя. Однако, в отличие от более тяжелых решений (таких как 1С:ERP или 1С:Комплексная автоматизация), 1С:УНФ имеет свои архитектурные особенности.

Рассмотрим, по каким измерениям программа позволяет ограничивать доступ в типовом варианте (версии 1.6 и 3.0):

1. Организации: пользователь видит документы только по тем юридическим лицам, к которым у него есть доступ.
2. Группы контрагентов: можно разрешить работу только с определенными клиентами.
3. Группы номенклатуры: ограничение видимости определенных категорий товаров.
4. Кассы и банковские счета: ограничение доступа к денежным средствам.
5. Физические лица: доступ к персональным данным сотрудников.

Как мы видим, измерение Структурные единицы (подразделения или склады) в этом списке отсутствует. Это осознанное решение разработчиков, направленное на сохранение высокой производительности системы. Внедрение RLS по каждому подразделению в каждом документе существенно усложняет SQL-запросы к базе данных, что может привести к замедлению работы интерфейса в компаниях с большим объемом данных.

Способ №1: Обходное решение через группы доступа контрагентов

Если бюджет на разработку ограничен, а разделение нужно «здесь и сейчас», проанализируем методику использования групп доступа контрагентов. Это решение является своего рода «костылем», но оно рабочее в определенных сценариях.

Разберем этот метод по шагам:

1. Перейдем в раздел Администрирование — Настройки пользователей и прав.
2. Установим флаг Ограничивать доступ на уровне записей.
3. Включим опцию Группы доступа контактов и контрагентов.
4. Создадим группы доступа, названия которых соответствуют вашим подразделениям (например, «Отдел Москва», «Отдел Спб»).
5. В карточке каждого контрагента укажем соответствующую группу доступа.
6. В настройках профиля пользователя укажем, с какими группами контрагентов он может работать.

Важный нюанс: при такой настройке пользователь не увидит документы (Заказы покупателей, Расходные накладные), если в них указан контрагент, не входящий в его разрешенную группу. Однако это не решает проблему разделения внутренних документов (Перемещения, Сборки) и требует жесткой дисциплины при ведении справочника контрагентов.

Способ №2: Ограничение по полю «Ответственный»

Рассмотрим ситуацию, когда сотрудникам нужно видеть только «свои» документы. В 1С:УНФ практически в каждом документе есть реквизит Ответственный. Выясним, как использовать это для фильтрации.

В настройках прав доступа можно создать профиль, который разрешает чтение документов только в том случае, если текущий пользователь совпадает со значением в поле Ответственный. Это функциональное ограничение, которое настраивается через стандартные роли в конфигураторе или через настройки прав в режиме «1С:Предприятие». Для быстрого решения этой задачи подойдёт расширение для фильтрации документов продажи по ответственному менеджеру.

Минусы подхода: руководитель подразделения в таком случае не сможет видеть документы своих подчиненных, если он не указан в них ответственным. Также это не позволяет реализовать коллективный доступ внутри одного отдела.

Способ №3: Использование расширений конфигурации (Профессиональный подход)

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

В расширении необходимо выполнить следующие действия:

1. Добавить новый вид доступа в механизме RLS (если используется БСП — Библиотека стандартных подсистем).
2. Для каждого типа документа (например, ЗаказПокупателя) прописать шаблон ограничения доступа в языке запросов.

Пример логики запроса для шаблона RLS (схематично):

ГДЕ СтруктурнаяЕдиница В (
    ВЫБРАТЬ ДоступныеПодразделения.Подразделение 
    ИЗ Справочник.Пользователи.ДоступныеПодразделения КАК ДоступныеПодразделения 
    ГДЕ ДоступныеПодразделения.Ссылка = &ТекущийПользователь
)

Использование расширения позволяет реализовать полноценный фильтр по справочнику СтруктурныеЕдиницы. Мы можем добавить в карточку пользователя или в его настройки (например, через механизм дополнительных реквизитов) список доступных ему складов и подразделений, и система будет автоматически отсекать лишние записи во всех динамических списках. Для настройки подобных правил без доработки кода можно использовать расширение для разграничения прав доступа с гибкими отборами.

Проблема глобального поиска и индексации

При внедрении любых ограничений RLS (штатных или кастомных) мы обязательно столкнемся с проблемой Глобального поиска. В 1С:УНФ реализован механизм полнотекстового поиска, который индексирует данные. Бывают ситуации, когда пользователь вводит номер документа в строку поиска и видит заголовок документа, к которому у него нет доступа по RLS. При попытке открытия система выдаст ошибку доступа, но сам факт наличия данных будет «подсвечен».

Чтобы минимизировать риски утечки информации, разберем необходимые меры:

• Необходимо настроить регламентное задание ОбновлениеИндексаППД (Полнотекстового поиска данных).
• В критически важных случаях рекомендуется полностью отключать полнотекстовый поиск для ролей с ограниченным доступом, оставляя поиск только по стандартным фильтрам в списках.
• Проверьте, чтобы права были ограничены не только на «Чтение», но и на «Просмотр», иначе данные могут попадать в отчеты, даже если они скрыты в списках.

Подведение итогов и рекомендации

Выясним причину, по которой внедрение RLS по подразделениям требует осторожности. Каждое правило RLS — это дополнительное условие JOIN или WHERE в SQL-запросе к базе данных. Если вы планируете ограничивать доступ по подразделениям для компании, где работают 50+ активных пользователей одновременно, будьте готовы к оптимизации серверной части.

Резюмируем наши действия:

1. Если задача простая и касается только продаж — попробуйте использовать группы доступа контрагентов.
2. Если нужно жесткое разделение по складам и отделам — заказывайте или разрабатывайте расширение.
3. Всегда проверяйте работу отчетов после настройки прав. Иногда RLS корректно скрывает документы в списке, но в отчете «Остатки товаров» пользователь может увидеть общие цифры, если права на регистры накопления настроены некорректно.

Помните, что 1С:УНФ — это гибкий инструмент, и отсутствие функции в «коробке» не означает невозможность её реализации. Правильный подход к архитектуре прав доступа обеспечит безопасность ваших данных без ущерба для скорости работы программы.