Можно ли урезать права у типовой роли «Пользователь» в 1С:УПП 1.3 и как это сделать без ошибок?

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

В чем разница между правами «Чтение» и «Просмотр»

Проанализируем базовые механизмы платформы «1С:Предприятие». Для любого прикладного объекта метаданных права доступа разделены на интерактивные и программные:

1. Право «Просмотр» — определяет возможность видеть объект в пользовательском интерфейсе: открывать формы списков, формы документов, выбирать объект в полях ввода и находить его в структуре меню. Если пользователю нужно просто запретить видеть кассовые документы в интерфейсе, достаточно снять право «Просмотр».
2. Право «Чтение» — низкоуровневое платформенное право, позволяющее считывать данные объекта из базы данных как программно (в запросах, при проведении других документов, обращении через точку), так и платформенными механизмами.

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

1. Нарушение ссылочной целостности: кассовый ордер может выступать регистратором в регистрах накопления (например, по взаиморасчетам), значением субконто на счетах бухгалтерского учета или документом-основанием в связанных цепочках. При попытке сформировать отчет или провести документ, где встречается ссылка на ПКО, немодифицированный код без привилегированного режима или запросы без инструкции ВЫБРАТЬ РАЗРЕШЕННЫЕ аварийно завершатся с системной ошибкой Нарушение прав доступа.
2. Формирование представлений: при отображении ссылок в отчетах платформе требуется получить стандартное представление документа (номер и дату). Полный запрет чтения заблокирует чтение ссылки.

Почему нельзя просто скопировать и переименовать роль «Пользователь»

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

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

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

Решение 1: Использование штатного механизма RLS (Ограничение на уровне записей)

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

Разберем по шагам, как настроить ограничение штатно:

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

Решение 2: Ограничение доступа на уровне полей (Field-level RLS)

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

В шаблоне ограничения RLS для права «Чтение» на документ ПриходныйКассовыйОрдер настраиваются раздельные условия:

1. Для служебных полей Ссылка, Номер, Дата доступ оставляется открытым (или задается условие ГДЕ ИСТИНА). Это позволяет платформе формировать представления и не вызывать исключений при обращении к ссылке.
2. Для всех остальных реквизитов (контрагент, сумма, статья ДДС, комментарий) прописывается условие ГДЕ ЛОЖЬ.

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

Решение 3: Использование привилегированного режима при снятии прав

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

Рассмотрим, как обеспечить выполнение фоновых и расчетных алгоритмов без ошибок:

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

УстановитьПривилегированныйРежим(Истина);
// Выполнение запроса или обращение к реквизитам недоступного документа
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   ПКО.Ссылка,
    |   ПКО.СуммаДокумента
    |ИЗ
    |   Документ.ПриходныйКассовыйОрдер КАК ПКО
    |ГДЕ
    |   ПКО.Ссылка = &Ссылка";
Запрос.УстановитьПараметр("Ссылка", ДокументСсылка);
Результат = Запрос.Выполнить();
УстановитьПривилегированныйРежим(Ложь);

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