Почему новая подсистема не видна пользователю с правами Администратора в 1С:Бухгалтерия 3.0?

← На главную

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

Анализируем причину: механизм синхронизации ролей в БСП

Для начала разберем, как 1С работает со списком ролей. В типовых решениях, таких как 1С:Бухгалтерия предприятия 3.0, управление доступом осуществляется не напрямую через роли в Конфигураторе, а через справочники Профили групп доступа и Группы доступа в пользовательском режиме. За это отвечает подсистема "Управление доступом" из состава БСП.

Проанализируем поведение системы при входе пользователя. В этот момент срабатывает программный механизм синхронизации. Программа сравнивает роли, назначенные пользователю в Конфигураторе, с теми, что прописаны в его группах доступа. Если обнаруживается расхождение, БСП программно перезаписывает набор ролей пользователя информационной базы.

Главная особенность: когда в наборе прав пользователя присутствует профиль Администратор, системе назначается роль ПолныеПрава. В логике БСП заложено правило: если у пользователя есть полные права, то все остальные роли считаются избыточными и могут быть удалены из списка активных ролей при входе. Это делается для оптимизации производительности и упрощения структуры прав, так как роль ПолныеПрава по определению должна давать доступ ко всему функционалу.

Выясняем причину невидимости подсистемы

Почему же администратор не видит подсистему, если у него есть "все права"? Здесь важно разделять право доступа к данным и право на Просмотр элемента интерфейса. Рассмотрим ситуацию по шагам:

Вы создали новую подсистему и новую роль (например, ДоступКНовойПодсистеме).
В этой новой роли вы установили галочку Просмотр для вашей подсистемы.
Вы создали профиль групп доступа, включили туда эту роль и назначили его пользователю.
В этот момент все работает: роль ДоступКНовойПодсистеме активна, интерфейс отображается.
Как только вы добавляете роль ПолныеПрава (через профиль Администратор), механизм БСП при входе пользователя видит "Полные права" и очищает роль ДоступКНовойПодсистеме как лишнюю.

В итоге у администратора остается только одна роль — ПолныеПрава. Если в этой типовой роли в Конфигураторе не стоит галочка Просмотр напротив вашей новой подсистемы, то 1С абсолютно логично скрывает этот раздел из интерфейса. Администратор имеет право открывать любые документы внутри подсистемы (по прямой ссылке), но самого пункта меню он не видит.

Вариант решения №1: Изменение состава роли ПолныеПрава

Самый простой и правильный с точки зрения архитектуры способ — включить новую подсистему в состав прав типовой роли ПолныеПрава. Рассмотрим, как это сделать:

Откройте Конфигуратор и найдите роль ПолныеПрава.
В дереве объектов метаданных найдите вашу новую подсистему.
Установите для роли ПолныеПрава право Просмотр на эту подсистему.
Не забудьте также проверить права на все объекты (справочники, документы, отчеты), входящие в подсистему, для этой же роли.

Важный нюанс: многие разработчики стараются не "дербанить" типовые роли, чтобы не усложнять процесс обновления конфигурации. Однако в случае с ролью ПолныеПрава это оправдано, так как администратор системы действительно должен видеть все разделы без исключения.

Вариант решения №2: Исправление логики БСП (та самая «одна строчка»)

Если вы категорически не хотите менять состав роли ПолныеПрава, можно внести изменения в программный код, который отвечает за очистку "лишних" ролей. Нам нужно найти модуль, отвечающий за установку ролей пользователя.

Обычно это серверный общий модуль УправлениеДоступомСлужебный или ПользователиСлужебный. Рассмотрим примерный алгоритм поиска нужного места:

Найдем процедуру УстановитьРолиПользователя.
Внутри этой процедуры располагается проверка наличия роли ПолныеПрава в массиве назначаемых ролей.
Проанализируем примерный код, который нужно изменить:


// Пример логики в БСП
Если РолиДляУстановки.Содержит("ПолныеПрава") Тогда
    // В типовом варианте здесь может происходить очистка массива других ролей
    // Чтобы сохранить ваши роли, это условие нужно модифицировать или закомментировать
    // РолиДляУстановки.Очистить(); 
    // РолиДляУстановки.Добавить("ПолныеПрава");
КонецЕсли;

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

Вариант решения №3: Работа с Расширениями конфигурации

Если вы создали подсистему в Расширении, ситуация становится еще интереснее. Типовая роль ПолныеПрава из основной конфигурации ничего не знает об объектах расширения. Чтобы решить проблему в рамках расширения, выполните следующие действия:

В расширении создайте свою роль, например, Администратор_Расширение.
Дайте этой роли полные права на все объекты расширения и право Просмотр на подсистему расширения.
В этой же роли добавьте право Администрирование (или другие системные права, если это необходимо).
В пользовательском режиме создайте новый профиль "Администратор расширения" и назначьте его администраторам.

Чтобы БСП не удаляла эту роль у администратора, убедитесь, что в расширении не переопределена логика синхронизации. В современных версиях БСП (начиная с 3.0 и выше) работа с ролями расширений автоматизирована, но требует корректного заполнения справочника Идентификаторы объектов метаданных. Для этого запустите программу с параметром:

/С ЗапуститьОбновлениеИнформационнойБазы