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