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