Почему затираются права пользователей в Конфигураторе 1С и как правильно настраивать доступ в конфигурациях на БСП?

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

Архитектурный принцип БСП: «Предприятие — ведущее, Конфигуратор — ведомый»

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

Давайте проанализируем, как связаны сущности в системе:

1. В режиме «1С:Предприятие» существует справочник Пользователи. Каждая запись в этом справочнике ссылается на реального пользователя информационной базы (ИБ) в Конфигураторе.
2. Связующим звеном выступает уникальный идентификатор (GUID), который хранится в скрытом реквизите справочника ИдентификаторПользователяИБ.
3. БСП берет на себя задачу автоматического поддержания актуальности списка ролей в Конфигураторе на основе тех настроек, которые сделаны в пользовательском интерфейсе. Любое ручное вмешательство разработчика в Конфигураторе расценивается системой как несанкционированное отклонение, которое необходимо устранить.

Почему ручные изменения в Конфигураторе «слетают»? Разбираем механизм синхронизации

Выясним причину, по которой затираются проставленные вручную роли. БСП запускает механизмы синхронизации (перезаписи) ролей пользователя ИБ «поверх» конфигуратора в следующие моменты:

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

Таким образом, Конфигуратор постоянно приводится в соответствие с данными, хранящимися в регистрах и справочниках подсистемы управления доступом БСП.

Особенности профиля «Администратор» и почему у него пропадают другие роли

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

Это стандартное, жестко заложенное поведение БСП, связанное с оптимизацией производительности:

• Если пользователю назначен предопределенный профиль «Администратор», система связывает его с системными ролями ПолныеПрава и АдминистраторСистемы (или Администрирование).
• Поскольку роль ПолныеПрава по умолчанию дает неограниченный доступ ко всем объектам метаданных в обход любых ограничений RLS (Row Level Security), БСП считает избыточным хранить другие роли в профиле этого пользователя.
• При первой же синхронизации процедура обновления ролей принудительно очищает у администратора все роли, кроме базовых административных. Пытаться вручную добавить ему другие роли в Конфигураторе абсолютно бесполезно.

Как правильно добавить новую роль из Конфигуратора в профиль безопасности?

Если мы создали новую роль в Конфигураторе, нам нужно сделать так, чтобы БСП «увидела» ее в режиме «1С:Предприятие» и позволила добавить в нужный профиль групп доступа. Разберем этот процесс по шагам:

1. Создайте роль в Конфигураторе и настройте права для объектов метаданных.
2. Для того чтобы БСП зарегистрировала новую роль в своей системе ведения метаданных, необходимо обновить справочник ИдентификаторыОбъектовМетаданных. Для этого запустите базу в режиме «1С:Предприятие» с параметром командной строки: /C ЗапуститьОбновлениеИнформационнойБазы Или воспользуйтесь специализированной обработкой из состава БСП: ИнструментыРазработчикаОбновлениеВспомогательныхДанных.epf.
3. После обновления справочника перейдите в раздел Администрирование — Настройки пользователей и прав — Профили групп доступа.
4. Создайте новый профиль (или откройте существующий), найдите вашу новую роль в списке разрешенных ролей и отметьте ее галочкой.
5. Включите пользователя в группу доступа, которой назначен данный профиль. БСП автоматически пропишет эту роль пользователю в Конфигураторе.

Программная проверка прав: почему нельзя использовать РольДоступна()

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

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

// ПРИМЕР КОДА С ОШИБКОЙ
Если РольДоступна("ИнтерактивноеОткрытиеВнешнихОбработок") Тогда
    // Выполняем действие, доступное только этой роли
Иначе
    ВызватьИсключение "Доступ запрещен!";
КонецЕсли;

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

Чтобы избежать подобных багов, по стандартам разработки 1С необходимо использовать функции БСП. Перепишем этот код правильно:

// ПРАВИЛЬНЫЙ ВАРИАНТ ПРОВЕРКИ
Если Пользователи.РолиДоступны("ИнтерактивноеОткрытиеВнешнихОбработок") Тогда
    // Данный блок кода успешно выполнится и для Администратора, и для обычного пользователя с этой ролью
Иначе
    ВызватьИсключение "Доступ запрещен!";
КонецЕсли;

Давайте проанализируем, как работает функция Пользователи.РолиДоступны() изнутри:

• Она может принимать как одну роль, так и список ролей через запятую или в виде массива.
• Первым делом функция проверяет, является ли текущий пользователь полноправным (администратором), используя вызов Пользователи.ЭтоПолноправныйПользователь().
• Если у пользователя есть полные права, функция **всегда возвращает Истина**, независимо от того, отмечена ли проверяемая роль в Конфигураторе физически.
• Если пользователь не обладает полными правами, функция корректно проверяет его физический набор ролей, учитывая также возможность работы в привилегированном режиме.

Резюме

Для успешной и бесконфликтной работы с правами в современных конфигурациях 1С всегда придерживайтесь правила: все настройки прав производятся исключительно в режиме «1С:Предприятие» через профили и группы доступа. Забудьте о ручном редактировании ролей пользователей в Конфигураторе, а при написании программного кода всегда используйте метод Пользователи.РолиДоступны() вместо устаревшего РольДоступна(). Это убережет вашу систему от неожиданных сбоев и обеспечит корректную работу прав для всех категорий пользователей.