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

← На главную

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

Анализ проблемы: почему 1С не пускает пользователя?

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

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


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

КонецПроцедуры

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


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

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

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

Решение 1: Использование системной роли "Базовые права"

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

Рассмотрим преимущества этого подхода:

Эта роль дает ровно то, что нужно для старта сеанса: права на запуск клиентов (тонкого, толстого, веб-клиента).
Она предоставляет права на чтение базовых констант, параметров сеанса и системных справочников, необходимых платформе для отрисовки интерфейса.
Доступ к бизнес-объектам (контрагентам, номенклатуре, документам) эта роль не предоставляет.

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

Решение 2: Обход проверки с помощью Расширений конфигурации

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

Создадим простое расширение. Посмотрим, как можно заимствовать функцию проверки и переопределить её логику с помощью директивы &Вместо.


&Вместо("ЕстьДоступныеПраваДляЗапускаКонфигурации")
Функция НашеРасширение_ЕстьДоступныеПраваДляЗапускаКонфигурации()
    
    // Сначала проверим наличие наших кастомных ролей
    Если РольДоступна("НашаСамописнаяРоль_Менеджер") ИЛИ РольДоступна("НашаСамописнаяРоль_Склад") Тогда
        Возврат Истина;
    КонецЕсли;
    
    // Если наших ролей нет, вызываем стандартную логику
    Возврат ПродолжитьВызов();
    
КонецФункции

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

Скрытые требования к минимальным правам (чек-лист)

Если мы создаем собственную минимальную роль полностью с нуля и обходим проверку через расширение, нам необходимо учесть скрытые требования платформы и БСП. Недостаточно просто установить галочки "Запуск тонкого/толстого клиента". Чтобы база корректно открылась и не выдала критическую ошибку на моменте загрузки интерфейса, разберем необходимые права для нашей кастомной роли:

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

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