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

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

Анализ проблемы: невидимость документа при добавлении ролей

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

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

Особенности механизма «Использовать основные роли»

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

Вам не требуется заходить в справочник пользователей и вручную проставлять права. Система динамически «подмешивает» основную роль расширения при авторизации пользователя. Но важно понимать: в платформе 8.3 права расширения суммируются с правами основной конфигурации по принципу «ИЛИ». Если в вашей новой роли есть ограничения по доступу к самому объекту данных (например, конфликтующие ограничения на уровне записей - RLS), это может привести к тому, что документ просто исчезнет из видимости.

Права на новые реквизиты в заимствованных объектах

Посмотрим на правила предоставления прав на новые реквизиты:

1. Типовые роли из основной конфигурации ничего не знают о добавленном вами реквизите. Даже роль с полными правами из основной базы не даст доступа к реквизиту расширения по умолчанию.
2. Чтобы пользователь увидел новый реквизит на форме, права на его Чтение и Просмотр обязательно должны быть прописаны в одной из ролей внутри самого расширения.
3. Если документ перестал быть виден целиком, вероятнее всего, произошел конфликт объединения прав.

Расширение типовых ролей (Режим 8.3.15 и выше)

Вместо того чтобы создавать новые «Основныe» роли и пытаться выстроить каскад из прав, рассмотрим более изящный метод, доступный начиная с версии платформы 8.3.15.

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

Этот подход гораздо надежнее, так как новые права автоматически получат именно те пользователи, которым эта роль уже назначена в основной базе. Вам не придется назначать права «всем подряд» через механизм основных ролей расширения.

Использование привилегированного режима

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

Достаточно повысить привилегии непосредственно перед выполнением запроса. Разберем на примере:

УстановитьПривилегированныйРежим(Истина);

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |    ЗаказПоставщику.НовыйРеквизитРасширения КАК НовыйРеквизит
    |ИЗ
    |    Документ.ЗаказПоставщику КАК ЗаказПоставщику
    |ГДЕ
    |    ЗаказПоставщику.Ссылка = &Ссылка";

Запрос.УстановитьПараметр("Ссылка", ДокументСсылка);
РезультатЗапроса = Запрос.Выполнить();

УстановитьПривилегированныйРежим(Ложь);

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

Проблема кэширования: почему помогает перезагрузка

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

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