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

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

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

Механизм сложения ролей: почему расширение не «отбирает» права

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

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

Способ 1. Создание модифицированной роли в основной конфигурации

Это наиболее стабильный и производительный метод, когда речь идет о ролях, затрагивающих тысячи объектов. Рассмотрим его по шагам:

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

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

Способ 2. Использование расширения через полное замещение роли

Если принципиально важно не вносить изменения в основную конфигурацию, можно пойти по пути расширения. Однако этот путь требует внимательности при работе с большим объемом объектов.

Для реализации этого метода необходимо:

1. Создать расширение и добавить в него новую роль.
2. Заимствовать все необходимые объекты метаданных (справочники, документы, регистры) в расширение.
3. Важный нюанс: при заимствовании объектов необходимо проверять права на стандартные реквизиты (Ссылка, Номер, Дата, Проведен). Платформа не всегда автоматически проставляет права на них в расширении, и их приходится устанавливать вручную.
4. В расширенной роли отключить право Сохранение данных пользователя.
5. Исключить у пользователя оригинальную роль из основной конфигурации. Это критически важно, иначе сработает механизм сложения прав, описанный выше.

Рассмотрим пример кода, который может понадобиться, если вы решите программно проверять наличие права в расширении:

Если ПравоДоступа("СохранениеДанныхПользователя", Метаданные.Роли.МояНоваяРольИзРасширения) Тогда
    // Логика, если право есть
Иначе
    // Логика, если право отсутствует
КонецЕсли;

Способ 3. Программное управление интерфейсом через расширение

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

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

Пример реализации в общем модуле (перехват события ПриСозданииНаСервере):

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

Разберем подробнее этот подход. Свойство формы ИзменяетСоставФорм напрямую управляет доступностью команды настройки. Установив его в значение Ложь, мы блокируем пользователю доступ к кастомизации интерфейса, при этом нам не нужно заимствовать 1000 объектов в расширение для изменения прав доступа.

Выводы и рекомендации

Подводя итог, отметим важные моменты, которые следует учитывать при работе с ролями:

• Помните, что в 1С нет «запрещающих» ролей. Вы не можете создать роль «Запрет чего-либо» и просто добавить её пользователю — она не перекроет уже имеющиеся разрешения.
• Заимствование огромного количества объектов (более 1000) в расширение только ради изменения одной галочки в роли — это путь к сложным обновлениям. Любое изменение типа реквизита в основной базе приведет к тому, что расширение откажется подключаться.
• Если конфигурация типовая (на базе БСП), используйте Профили групп доступа для управления составом ролей у пользователей.
• Для точечного запрета интерфейсных функций (как «Сохранение данных пользователя») наиболее эффективным является программный метод через расширение общего модуля, так как он минимизирует риски при обновлении и не раздувает объем метаданных.

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