При активной разработке в среде 1С:Предприятие 8 программисты часто сталкиваются с ситуацией, когда при создании любого нового объекта метаданных (будь то справочник, документ, общая форма или команда) в списке его прав уже проставлены галочки для некоторых ролей. Часто это роли вроде ПолныеПрава, АдминистраторСистемы или специфические "Базовые права". На первый взгляд это может показаться программным сбоем или "глюком" конфигуратора, особенно если эти роли не выбраны в качестве Основных ролей в свойствах корня конфигурации.
В данной статье мы подробно разберем механизм, который управляет этим поведением, выясним, где находится нужная настройка, и проанализируем, почему архитектурно такое решение является спорным, но практически необходимым.
Рассмотрим основной механизм платформы, отвечающий за автоматизацию назначения прав. Основная причина "самопроизвольного" появления ролей в новых объектах заключается в специфическом свойстве самой роли, которое скрыто внутри ее конструктора. Проанализируем, как его найти и проверить:
Общие -> Роли.БазовыеПрава), и откроем ее двойным кликом (вызовем окно редактирования роли).Если этот флаг установлен, платформа при создании любого нового объекта метаданных автоматически назначает данной роли предопределенный набор прав для этого типа объекта. Рассмотрим подробнее, почему это свойство не выведено в общую палитру свойств: оно влияет не на поведение роли в режиме "1С:Предприятие", а на поведение самого Конфигуратора в процессе разработки. Это инструмент автоматизации работы программиста.
Выясним причину существования этой функции. Представим конфигурацию 1С:ERP или 1С:Управление торговлей, в которой сотни и тысячи объектов метаданных. Если разработчик добавляет новый справочник, ему пришлось бы вручную заходить в роль ПолныеПрава и проставлять галочки на все виды действий: Чтение, Добавление, Изменение, Удаление, Просмотр, Интерактивное добавление и так далее.
Чтобы избежать этой рутины, для административных ролей включается признак Устанавливать права для новых объектов. Платформа сама определяет стандартный набор прав для каждого типа метаданных:
Справочников и Документов: полный набор прав (от чтения до интерактивного удаления).Отчетов и Обработок: права на Использование и Просмотр.Общих команд и Форм: право на Просмотр.Однако, как отмечают опытные разработчики, с точки зрения "чистой архитектуры" это решение неоднозначно. Оно нарушает принцип минимальных привилегий, согласно которому права должны быть закрыты по умолчанию, пока они явно не разрешены. Именно поэтому в типовых решениях от фирмы "1С" этот флаг обычно стоит только у ролей ПолныеПрава и АдминистраторСистемы.
Проанализируем ситуацию, когда данный флаг может привести к техническим сложностям. При выполнении операции сравнения и объединения конфигураций (особенно при обновлении нетиповых решений) настройки этого свойства могут неявно влиять на результат.
Если в вашей основной конфигурации у роли включен флаг автоназначения прав, а в загружаемом файле поставки (.cf) у этой же роли флаг снят, то при создании новых объектов в процессе объединения права могут проставиться непредсказуемо. Рекомендуем всегда проверять состояние этого флага у кастомных ролей перед началом масштабных обновлений, чтобы не "замусорить" права доступа лишними разрешениями.
В современной среде разработки 1C:EDT (Enterprise Development Tools) управление этим свойством переходит на уровень XML-файлов. Если вы посмотрите на исходный код роли в формате XML, вы увидите соответствующий тег:
<Role xmlns="http://v8.1c.ru/8.3/MDClasses" uuid="... ">
<name>ПолныеПрава</name>
<synonym>
<key>ru</key>
<value>Полные права</value>
</synonym>
<setForNewObjects>true</setForNewObjects>
<setForAttributesByDefault>true</setForAttributesByDefault>
</Role>
Параметр setForNewObjects со значением true как раз и является тем самым флагом. При групповой разработке через Git иногда возникают конфликты слияния в файлах ролей. Если при разрешении конфликта этот тег был случайно изменен, вся команда разработчиков может столкнуться с тем, что в новые объекты начнут добавляться неожиданные роли.
Рассмотрим ситуацию с точки зрения безопасности данных. Использование этой опции для ролей с ограниченным доступом (например, "Только чтение" или "Менеджер по продажам") крайне опасно. Если разработчик по ошибке или в целях "временного удобства" включит этот признак для рядовой роли, то любой новый созданный объект — будь то секретный документ с зарплатами или регистр с персональными данными — сразу станет доступен пользователям с этой ролью.
Важное правило: права должны добавляться осознанно. Если вы используете БСП (Библиотеку стандартных подсистем), управление доступом обычно происходит через справочник Профили групп доступа. В этом случае флаг в конфигураторе должен быть включен исключительно для роли полных прав. Все остальные права должны обновляться через механизмы БСП (обработчики обновления или ручную настройку профилей).
Если вы обнаружили, что в конфигурации накопилось много объектов с "лишними" ролями, выполните следующие шаги:
Устанавливать права для новых объектов и снимите его, если эта роль не административная.Правка -> Все роли в окне редактирования конкретного объекта) или обработками по автоматизации изменения метаданных, если объектов очень много.Таким образом, мы выяснили, что автоматическое добавление ролей — это не ошибка системы, а штатный механизм платформы 1С, предназначенный для облегчения жизни разработчика при настройке административного доступа. Грамотное использование этого свойства позволяет поддерживать порядок в правах доступа и избегать лишних трудозатрат при расширении функционала системы.