← На главную

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

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

Понимание механизма управления доступом и причин сброса ролей

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

1. Назначение ролей через конфигуратор: Одна из самых частых ошибок, приводящих к сбросу ролей – это их назначение непосредственно в конфигураторе. В современных версиях платформы 1С и типовых конфигурациях, использующих БСП, управление правами доступа осуществляется преимущественно в режиме предприятия. Если мы назначаем роли пользователям в конфигураторе, эти изменения могут быть перезаписаны или проигнорированы при следующих событиях:
   • Сохранение профилей в режиме предприятия: При редактировании и сохранении профиля доступа в пользовательском режиме, система может перезаписать права всех пользователей, ассоциированных с этим профилем, тем самым отменив ручные изменения, сделанные в конфигураторе.
   • Обновление конфигурации: При каждом обновлении конфигурации или ее расширений происходит перерегистрация и перестройка механизмов управления доступом, что часто включает перезапись или актуализацию профилей. Это может привести к тому, что роли, назначенные вне стандартных процедур, будут сброшены. При работе с большим количеством баз этот процесс можно автоматизировать, используя инструмент для массового фонового обновления и тестирования конфигураций 1С.
2. Логика общего модуля УправлениеДоступомСлужебный: В конфигурациях на базе БСП существует служебная процедура ОбновитьРолиПользователей в общем модуле УправлениеДоступомСлужебный. Эта процедура периодически или при определенных событиях пересчитывает и актуализирует права пользователей. В частности, для пользователей, отнесенных к администраторам (имеющих предопределенный профиль групп доступа «Администратор» или «Полные права»), эта процедура может очищать все роли и оставлять только те, которые, по мнению БСП, необходимы администратору, игнорируя при этом роли, добавленные расширениями. Это является основной причиной "слетания" ролей именно для пользователей с полными правами.
3. "Защита от опасных действий" (исторический контекст): В некоторых ранних версиях платформы 1С (особенно на этапах внедрения расширений) отключение флажка "Защита от опасных действий" для расширений иногда помогало предотвратить их исчезновение после обновления. Однако это скорее исключение и не является рекомендуемой практикой для актуальных версий.

Таким образом, проблема является многогранной и требует комплексного подхода, учитывающего как способ назначения ролей, так и специфику обработки прав для администраторов.

Корректное назначение ролей из расширений для обычных пользователей

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

Назначение ролей из расширений в пользовательском режиме

Рассмотрим по шагам, как мы можем корректно назначить роли из расширения, чтобы они не отключались автоматически:

1. Перейдите в раздел управления правами:
   • Запустите 1С в режиме предприятия.
   • Перейдите в раздел НСИ и администрирование.
   • Далее выберите Настройки пользователей и прав.
2. Работа с профилями групп доступа:
   • В Настройках пользователей и прав найдите пункт Профили групп доступа и откройте его.
   • Создание нового профиля: Мы рекомендуем создать отдельный профиль доступа, который будет включать только необходимые роли из расширений, или же добавить эти роли в существующий профиль, если он подходит по функционалу. Для создания нового профиля нажмите кнопку Создать.
   • Добавление ролей из расширений в профиль: В новом или выбранном профиле вы увидите список доступных ролей. Роли из расширений будут отображаться в этом списке наравне с ролями основной конфигурации. Обычно их названия начинаются с префикса расширения, или они могут быть явно помечены как принадлежащие расширению. Мы устанавливаем флажки напротив тех ролей расширения, которые хотим включить в данный профиль.
   • Сохранение профиля: После выбора необходимых ролей, сохраните изменения в профиле.
3. Создание и настройка группы доступа:
   • Вернитесь в Настройки пользователей и прав и откройте пункт Группы доступа.
   • Создание новой группы доступа: Нажмите Создать группу.
   • Связывание группы с профилем: В новой группе доступа выберите созданный нами или модифицированный профиль из списка Профиль. Таким образом, все пользователи, которые будут включены в эту группу, автоматически получат права, определенные выбранным профилем.
   • Сохранение группы доступа: Сохраните новую группу доступа.
4. Назначение пользователей в группу доступа:
   • В открытой группе доступа перейдите на вкладку Участники.
   • Используйте кнопку Подобрать или Добавить, чтобы включить в эту группу конкретных пользователей, для которых мы хотим, чтобы роли из расширения были активны.
   • Сохраните изменения в группе доступа.

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

Особенности работы с ролями для пользователей с полными правами

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

Полные права и роли из расширений: почему они конфликтуют?

Давайте подробно проанализируем эту ситуацию:

1. Избыточность ролей для полных прав: Платформа 1С устроена таким образом, что роль "Полные права" (или профиль "Администратор") предоставляет максимально возможный доступ ко всем объектам конфигурации и данным. С точки зрения системы, любые дополнительные роли для такого пользователя являются избыточными, а иногда даже могут приводить к нежелательным последствиям. БСП содержит логику, которая при обновлении ролей для администраторов удаляет все "лишние" роли, оставляя только предопределенные для профиля "Администратор".
2. Потенциальное торможение работы базы: Дополнительные роли, даже для пользователей с полными правами, могут увеличить объем метаданных, которые система должна обрабатывать при проверке прав доступа. Это, в свою очередь, может привести к незначительному, но все же возможному замедлению работы базы данных и снижению производительности. Система старается оптимизировать этот процесс, и удаление "ненужных" ролей для администраторов является частью этой оптимизации.
3. Специфические "хотелки" и сценарии: Иногда возникают ситуации, когда, несмотря на полные права, администратору требуется наличие конкретной роли из расширения. Это может быть обусловлено следующими причинами:
   • Видимость подсистем или команд: Некоторые подсистемы или команды в расширении могут быть привязаны к наличию определенной роли. Если администратору нужна видимость этих элементов интерфейса, а "Полные права" их почему-то не активируют (что бывает редко, но возможно при специфичном проектировании расширения или конфигурации), то роль расширения становится необходимой.
   • Ограничение доступа (парадоксально): В редких случаях разработчик может захотеть ограничить доступ администратора к определенным объектам расширения. Однако это обычно противоречит самой идеологии полных прав и требует очень тонкой настройки, чаще всего не через добавление, а через изменение или создание альтернативной роли "Полные права" внутри расширения.

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

Принудительное сохранение ролей расширений для администраторов через расширение конфигурации

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

Модификация процедуры "ОбновитьРолиПользователей" для сохранения ролей расширений

Как мы уже выяснили, процедура ОбновитьРолиПользователей в общем модуле УправлениеДоступомСлужебный отвечает за актуализацию ролей и может сбрасывать роли из расширений для администраторов. Мы можем вмешаться в ее работу, используя расширение конфигурации в режиме "ИзменениеИКонтроль", чтобы явно указать системе сохранять наши роли.

1. Создание расширения и заимствование модуля:
   • Мы создаем новое расширение конфигурации или используем существующее.
   • В расширении мы заимствуем общий модуль УправлениеДоступомСлужебный. Для этого в дереве объектов расширения находим Общие модули, затем УправлениеДоступомСлужебный, вызываем контекстное меню (правая кнопка мыши) и выбираем Добавить в расширение.
   • Важно установить для заимствованного модуля режим ИзменениеИКонтроль. Это позволит нам внедрить свой код в середину существующей процедуры, не перезаписывая ее целиком.
2. Изменение процедуры ОбновитьРолиПользователей:
   • Открываем заимствованный общий модуль в расширении и находим процедуру ОбновитьРолиПользователей.
   • Нам нужно найти блок кода, который обрабатывает роли для администраторов. Он выглядит примерно так (без вставки):
   Скопировать код

   
   Если Администраторы[ТекущийПользователь] <> Неопределено Тогда
       ТекущиеНовыеРоли = НовыеРоли;
       НовыеРоли = ТекущиеНовыеРоли.Скопировать(Новый Массив);
       Для Каждого КлючИЗначение Из ОбязательныеРолиАдминистратора Цикл
           НовыеРоли.Добавить.Роль = КлючИЗначение.Ключ;
       КонецЦикла;
       Для Каждого КлючИЗначение Из ДополнительныеРолиАдминистратора Цикл
           Если ТекущиеНовыеРоли.Найти(КлючИЗначение.Ключ, "Роль") = Неопределено Тогда
               Продолжить;
           КонецЕсли;
           НовыеРоли.Добавить.Роль = КлючИЗначение.Ключ;
       КонецЦикла;
       // ... здесь будет наша вставка ...
   КонецЕсли;
   

   Наша задача – вставить код таким образом, чтобы он добавлял в список НовыеРоли те роли из расширений, которые были у пользователя до обновления, но не были учтены стандартной логикой БСП. Место для вставки будет непосредственно перед КонецЕсли; этого блока.

• Вставка кода для сохранения ролей расширений:
  • Мы добавляем следующий код в процедуру ОбновитьРолиПользователей после всех стандартных циклов обработки ролей администратора, но до завершения условного блока Если Администраторы[ТекущийПользователь] <> Неопределено Тогда:
  Скопировать код

  
  #Вставка
  Для Каждого СтрРоль Из ТекущиеНовыеРоли Цикл
      Если ТипЗнч(СтрРоль.РольСсылка) = Тип("СправочникСсылка.ИдентификаторыОбъектовРасширений") Тогда
          ЗаполнитьЗначенияСвойств(НовыеРоли.Добавить(), СтрРоль);
      КонецЕсли;
  КонецЦикла;
  #КонецВставки
  

  Разберем этот код подробно:

  • ТекущиеНовыеРоли: Это переменная, которая в начале блока сохраняет исходный список ролей, которые были у пользователя до начала процесса обновления. Мы используем его, чтобы определить, какие роли, возможно, были "потеряны".
  • Для Каждого СтрРоль Из ТекущиеНовыеРоли Цикл: Мы перебираем все роли, которые были у пользователя изначально.
  • Если ТипЗнч(СтрРоль.РольСсылка) = Тип("СправочникСсылка.ИдентификаторыОбъектовРасширений") Тогда: Это ключевое условие. Мы проверяем тип значения поля РольСсылка для каждой строки роли. Если тип этой ссылки равен СправочникСсылка.ИдентификаторыОбъектовРасширений, это означает, что данная роль относится к объекту, который был создан в расширении. 1С хранит ссылки на объекты расширений именно в этом служебном справочнике.
  • ЗаполнитьЗначенияСвойств(НовыеРоли.Добавить(), СтрРоль);: Если роль идентифицирована как роль из расширения, мы добавляем новую строку в таблицу НовыеРоли (которая затем будет сохранена для пользователя) и копируем в нее все свойства из текущей строки СтрРоль. Функция Добавить() для табличной части (или аналогичного объекта) создает новую строку, а ЗаполнитьЗначенияСвойств копирует данные.

• Сохранение расширения: После внесения изменений сохраните расширение и обновите конфигурацию базы данных.

Этот код гарантирует, что любые роли, которые мы назначили пользователю с полными правами (через пользовательский режим), и которые относятся к расширениям, будут принудительно добавлены обратно в список ролей после обработки стандартной логикой БСП. Таким образом, даже для администраторов роли из расширений останутся активными.

Заключение

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

Для обычных пользователей без полных прав, мы выяснили, что наиболее стабильным и рекомендуемым решением является назначение ролей исключительно в пользовательском режиме через систему Профилей групп доступа и Групп доступа. Этот подход соответствует современной архитектуре платформы и обеспечивает устойчивость назначенных прав.

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

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