Можно ли ограничить права у базовой роли «Пользователь» в 1С:УПП 1.3?

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

Почему не удается скопировать типовую роль в конфигураторе?

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

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

Чтобы разрешить создание новых ролей, выполним следующие действия:

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

Что произойдет, если отключить право «Чтение» у роли «Пользователь»?

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

Проанализируем технические последствия отключения права Чтение на документ (например, ПриходныйКассовыйОрдер):

1. Фатальные ошибки запросов («Нарушение прав доступа»). В конфигурации УПП 1.3 многие механизмы проведения, формирования отчетов и закрытия месяца содержат запросы без обязательного модификатора ВЫБРАТЬ РАЗРЕШЕННЫЕ. Если такой типовой запрос попытается соединиться с таблицей кассовых документов, сеанс пользователя аварийно завершится системной ошибкой прав доступа.
2. Блокировка регистров и движений. Документ ПриходныйКассовыйОрдер часто выступает регистратором движений по взаиморасчетам, денежным средствам или бухгалтерским счетам, а также аналитикой (субконто). Лишив пользователя права физического чтения документа-регистратора, мы лишаем его возможности открывать или формировать движения по связанным регистрам.
3. Сбой в механизме структуры подчиненности. Критерий отбора СвязанныеДокументы строит полное дерево подчиненности. При отсутствии права чтения хотя бы на одну строку в цепочке документов попытка пользователя посмотреть связанные документы вызовет ошибку ограничения доступа.
4. Появление битых ссылок в интерфейсе. В полях документов и отчетов, где кассовый ордер выступает значением ссылки, пользователь вместо понятного номера и даты увидит системное представление <Объект не найден> с внутренним идентификатором (GUID).
5. Сложности при регулярных обновлениях. Измененная базовая роль потребует ручного сопоставления при каждом обновлении конфигурации. При появлении в новых релизах метаданных придется вручную определять, какие права должны быть добавлены в роль Пользователь, иначе новые механизмы перестанут работать.

Корректные способы решения задачи

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

Вариант 1. Разделение прав «Чтение» и «Просмотр»

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

Если в роли Пользователь оставить флаг Чтение, но снять флаг Просмотр:

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

Вариант 2. Ограничение через переключение интерфейсов

В конфигурациях на обычных формах, к которым относится УПП 1.3, видимость разделов и документов настраивается через объекты метаданных типа Интерфейс. Если пользователю не требуется работать с кассой, достаточно назначить ему специализированный интерфейс (например, «Интерфейс менеджера по продажам»), исключив из него кассовые подсистемы и журнал кассовых документов, а также отключить доступ к полному интерфейсу и меню «Операции».

Вариант 3. Программный запрет открытия формы

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

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

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

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