Как правильно использовать РольДоступна() и ограничивать права в 1С:ERP

← На главную

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

Разбор стандартного механизма проверки прав

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


&НаКлиенте 
Процедура ПриОткрытии(Отказ)
    Если Строка(ЭтаФорма.Объект.Статус) = "Закрыт" Тогда
        Разрешить = ПроверкаПравНаСервере();
        Если НЕ Разрешить Тогда
            Сообщить("У вас нет прав на изменение закрытых данных!", СтатусСообщения.Важное);
            ЭтаФорма.ТолькоПросмотр = Истина;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

&НаСервере
Функция ПроверкаПравНаСервере()
    // Проверка наличия конкретной роли у текущего пользователя
    Возврат РольДоступна("1Тест");
КонецФункции

На первый взгляд код выглядит логичным, но на практике он может не срабатывать для администраторов или, наоборот, работать некорректно после обновления системы. Выясним причину такого поведения.

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

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

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


&НаСервере
Функция ПроверкаПравНаСервере()
    // Сначала проверяем, является ли пользователь администратором
    Если Пользователи.ЭтоПолноправныйПользователь() Тогда
        Возврат Истина;
    КонецЕсли;
    
    // Если не администратор, проверяем конкретную прикладную роль
    Возврат РольДоступна("1Тест");
КонецФункции

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

Проблема синхронизации ролей: Конфигуратор vs Предприятие

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

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

Правильный алгоритм действий:

Создайте новую роль в Конфигураторе (например, 1Тест).
В режиме 1С:Предприятие перейдите в раздел «Администрирование» — «Настройки пользователей и прав» — «Профили групп доступа».
Создайте новый профиль и отметьте в списке вашу новую роль.
Создайте «Группу доступа», выберите созданный профиль и добавьте туда нужных пользователей.

Только такой подход гарантирует, что права не «слетят» после очередного обновления или изменения настроек пользователей.

Альтернативные способы реализации ограничений

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

1. Использование дополнительных прав пользователей

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

2. Проверка через группы доступа

Если логика требует проверки принадлежности пользователя к определенной группе, можно использовать методы анализа групп доступа. Это позволяет избежать жесткой привязки к именам ролей в программном коде.

3. Оптимизация через параметры сеанса

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