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

← На главную

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

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

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

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

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

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

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

Способ 1. Создание отдельной роли и точечная корректировка процедур запуска

Этот вариант является наиболее идеологически выверенным с точки зрения механизма прав, так как блокировка записи происходит на уровне метаданных и прав платформы.

Разберем последовательность действий:

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

При таком подходе карточки документов и справочников, открытые даже через расшифровку отчета, будут недоступны для редактирования на уровне платформы.

Способ 2. Блокировка записи через подписку на события (без изменения роли «Пользователь»)

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

Разберем логику реализации:

Создаем новую роль-маркер, например, ЗапретРедактированияДанных, и назначаем ее пользователю вместе с базовой ролью Пользователь.
Создаем новый общий модуль и объект метаданных ПодпискаНаСобытие.
В качестве источника указываем составной тип из всех справочников и документов, изменение которых нужно заблокировать.
В качестве события выбираем ПередЗаписью.

В обработчике проверяем наличие назначенной роли-маркера:


Процедура ЗапретЗаписиПередЗаписью(Источник, Отказ) Экспорт
    Если РольДоступна("ЗапретРедактированияДанных") Тогда
        Отказ = Истина;
        ВызватьИсключение "У вас нет прав на сохранение и изменение данных!";
    КонецЕсли;
КонецПроцедуры

Этот метод не затрагивает типовой код модулей конфигурации и не создает проблем при последующих накатах обновлений.

Способ 3. Изоляция интерфейса и блокировка расшифровки в отчетах

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

Выполним следующие настройки:

Настройка интерфейса: создаем отдельный интерфейс, в котором оставляем только команды вызова целевых отчетов. В свойствах интерфейса отключаем признак Переключаемый (устанавливаем значение Ложь), чтобы пользователь не мог самостоятельно переключиться на типовые меню Сервис или Справочники.
Защита от расшифровки: чтобы предотвратить интерактивный переход к объектам из сформированного табличного документа отчета, в коде вывода отчета устанавливаем свойство табличного документа:
```
ТабличныйДокумент.ТолькоПросмотр = Истина;
ТабличныйДокумент.Защита = Истина;
```
Переопределение события расшифровки: для элементов управления отчета на форме переопределяем событие ОбработкаРасшифровки, отключив стандартное поведение:
```
Процедура ПолеТабличногоДокументаОбработкаРасшифровки(Элемент, Расшифровка, СтандартнаяОбработка)
    СтандартнаяОбработка = Ложь;
КонецПроцедуры
```

Дополнительные механизмы защиты

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