Как правильно настроить права доступа на объекты в 1С 8.3 и почему не стоит использовать РольДоступна() в коде формы?

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

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

Выясняем причину ошибки «Недопустимое значение параметра (параметр номер '1')»

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

{Документ.ВводКритериевОценкиКачестваРаботыСотрудников.Форма.ФормаДокумента.Форма(69)}: Ошибка при вызове метода контекста (РольДоступна)
    Если Не РольДоступна("СозданиеКритериевОценки") И Не РольДоступна("ЧтениеКритериевОценки") Тогда
по причине:
Недопустимое значение параметра (параметр номер '1')

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

Основные причины возникновения этой ошибки на практике:

1. Опечатка в имени роли. Это самая частая причина. Достаточно случайно написать русскую букву «С» латинским символом «C», ошибиться в регистре букв или поставить лишний пробел, чтобы платформа перестала распознавать имя роли.
2. Динамическое обновление (демонский апдейт). Если новые роли СозданиеКритериевОценки и ЧтениеКритериевОценки были добавлены в конфигураторе, но обновление базы данных было выполнено динамически, текущий сеанс пользователя может еще «не знать» о существовании этих объектов в метаданных. В таком случае вызов метода также вернет ошибку. Решением будет полный перезапуск сеанса или монопольное обновление базы данных.

Почему программная проверка ролей в форме — это грубая ошибка (Стандарт #std737)

Посмотрим на код, который пытался реализовать разработчик в процедуре ПриСозданииНаСервере:

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    Если Не РольДоступна("СозданиеКритериевОценки") И Не РольДоступна("ЧтениеКритериевОценки") Тогда
        Отказ = Истина;
        Возврат;
    КонецЕсли;
КонецПроцедуры

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

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

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

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

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

Как правильно разделить права на «Создание» и «Чтение» в конфигураторе

Разберем по шагам, как решить задачу автора темы стандартными средствами платформы 1С без написания какого-либо программного кода в формах.

Для разделения прав на создание (редактирование) и чтение документов нам понадобятся две роли. Назовем их условно ДобавлениеИзменениеКритериевОценки и ЧтениеКритериевОценки.

В конфигураторе для каждой роли необходимо настроить соответствующий набор прав на нужные объекты метаданных (справочник и документ):

Настройка роли для чтения (только просмотр):

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

Настройка роли для создания и редактирования:

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

Платформа 1С самостоятельно проанализирует эти права при запуске сеанса. Если у пользователя есть только роль на чтение, система автоматически откроет форму документа в режиме «Только просмотр», заблокирует кнопки создания и изменения, не требуя от разработчика написания ни одной строчки кода.

Важные нюансы работы с БСП и пользователями с «Полными правами»

Автор сообщения №19 столкнулся с интересным эффектом: он вошел под пользователем с ролью ПолныеПрава, у которого не были отмечены новые роли, но при этом создание документов все равно оставалось доступным. Это абсолютно нормальное и задокументированное поведение системы.

Роль ПолныеПрава (или административный профиль) по определению предоставляет доступ ко всем объектам метаданных конфигурации. Наличие или отсутствие галочек напротив других ролей у такого пользователя не имеет значения — полные права перекрывают любые другие ограничения.

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

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

// Использование метода БСП вместо стандартного платформенного метода
Если Пользователи.РолиДоступны("СозданиеКритериевОценки") Тогда
    // Ваша программная логика
КонецЕсли;

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

Оптимизация интерфейса «Такси» и производительность системы

Проанализируем еще один важный аспект разработки под управляемый интерфейс «Такси». Автор темы планировал управлять доступностью элементов формы в процедуре ПриСозданииНаСервере.

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

Для оптимизации интерфейса рекомендуется использовать следующие подходы:

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

Таким образом, отказ от программного кода проверки прав в пользу стандартных механизмов настройки ролей в конфигураторе делает конфигурацию производительной, надежной и соответствующей стандартам фирмы «1С».