При работе с современными конфигурациями на платформе 1С:Предприятие 8.3 разработчики и системные администраторы часто сталкиваются с ситуацией, когда настройки прав в Конфигураторе и в режиме 1С:Предприятие (пользовательском) различаются. Возникает закономерный вопрос: какой набор прав в итоге применится к пользователю, и почему изменения, внесенные вручную в Конфигураторе, могут неожиданно исчезнуть?
В этой статье мы подробно разберем механизмы управления доступом, выясним роль Библиотеки стандартных подсистем (БСП) в этом процессе и проанализируем, как обеспечить стабильную работу прав доступа без риска их потери при очередном обновлении или входе пользователя в систему.
Разберем главный нюанс: в типовых конфигурациях (таких как Бухгалтерия предприятия 3.0, Управление торговлей 11, ERP и других), построенных на базе БСП, реализован механизм программного управления списком ролей пользователя. Рассмотрим подробнее, как это работает.
Когда вы открываете карточку пользователя в Конфигураторе и расставляете галочки напротив ролей, вы взаимодействуете с платформенным механизмом. Однако БСП имеет свой собственный "эталонный" список прав, который хранится в базе данных в виде справочников Профили групп доступа и Группы доступа.
Проанализируем ситуацию: если вы добавили роль пользователю напрямую в Конфигураторе, а в пользовательском режиме (в Группе доступа) эта роль за пользователем не закреплена, произойдет следующее:
Конфигураторе с тем набором, который полагается пользователю согласно его Группам доступа.ПользовательИнформационнойБазы) снимет её, чтобы привести состояние в соответствие с эталоном из пользовательского режима.Таким образом, итоговым набором прав всегда будет тот, который задан в пользовательском режиме через механизмы БСП.
Иногда специалисты пытаются игнорировать механизмы БСП, предпочитая "тотальный личный контроль" (как упоминалось в обсуждении). Выясним причины, почему такой подход считается рискованным и некорректным:
Конфигураторе.Разберем по шагам правильный алгоритм внедрения новой роли, чтобы она не "слетала" и корректно учитывалась системой:
Конфигураторе. Убедитесь, что у неё задано понятное имя и синоним.УправлениеДоступомПереопределяемый.Профиль групп доступа или отредактируйте существующий, отметив в списке вашу новую роль.Группу доступа, использующую данный профиль.После этих действий БСП сама добавит роль пользователю в Конфигураторе и будет поддерживать это состояние автоматически.
Если вы внесли массовые изменения или создали новые роли и хотите, чтобы БСП немедленно "узнала" о них, можно воспользоваться программным вызовом методов библиотеки. Рассмотрим пример кода, который инициирует обновление кэша ролей:
// Программное обновление справочника "Идентификаторы объектов метаданных"
// и кэша прав ролей в БСП
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
УправлениеДоступом.ОбновитьРазрешенныеРоли();
Этот код заставляет систему перечитать метаданные и обновить внутренние таблицы, в которых хранится информация о доступных ролях для профилей.
Для проверки того, какие именно права сейчас действуют у пользователя и откуда они "пришли", в БСП предусмотрен мощный инструмент. Посмотрим на него подробнее:
Отчет "Права доступа" (обычно доступен из карточки пользователя). Он позволяет увидеть сводную информацию:
Группу доступа получена та или иная роль.Если в этом отчете вы не видите роли, которую добавили в Конфигураторе, значит, система её скоро удалит. Это лучший способ самопроверки для администратора.
Проанализировав ситуацию, мы приходим к выводу, что попытки "обмануть" БСП и настраивать права напрямую в Конфигураторе приводят к созданию технического долга и нестабильности системы.
Запомним основные правила:
Конфигуратор используется только для создания самого объекта Роль и определения её статических прав (на чтение, запись и т.д.).Следование этим простым рекомендациям позволит вам избежать "магического" исчезновения прав у пользователей и обеспечит беспроблемное обновление конфигурации в будущем.