Как правильно запретить чтение и просмотр цен номенклатуры в 1С?

← На главную

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

Архитектура ролевой модели: почему нельзя создать одну «запрещающую» роль

Проанализируем базовый принцип работы системы прав в платформе 1С:Предприятие. Ролевая модель построена на принципе логического «ИЛИ» (аддитивность прав). Это означает следующее:

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

По этой причине идея создать роль вроде ЗапретПросмотраСебестоимости и указать в ней запрет не принесет результата, если у пользователя параллельно назначена типовая роль (например, МенеджерПоПродажам), где регистр доступен без ограничений. Чтобы ограничение RLS сработало, одинаковый шаблон ограничения доступа должен присутствовать абсолютно во всех ролях пользователя, имеющих доступ к объекту.

Разница между правами «Чтение» и «Просмотр»: подводные камни

Выясним причину, почему участники обсуждения рекомендуют снимать именно «Просмотр», а не «Чтение»:

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

Право «Чтение» управляет выборкой данных на уровне запросов к СУБД. Если забрать у пользователя право на чтение регистра сведений ЦеныНоменклатуры, то любая типовая процедура, которая обращается к этому регистру, завершится аварийным завершением. Например, при открытии или заполнении документа РеализацияТоваровУслуг вызываются штатные механизмы ценообразования. Запрос без ключевого слова РАЗРЕШЕННЫЕ тут же вызовет фатальное исключение платформы Нарушение прав доступа. Даже если запрос содержит РАЗРЕШЕННЫЕ, отсутствие прав на срез последних приведет к получению пустых значений (NULL), что сломает расчет сумм и проведение документа.

Способ 1. Использование штатного RLS конфигурации по типам цен

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

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

Способ 2. Клонирование ролей и исключение прав

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

Обязательно создаем резервную копию информационной базы перед редактированием прав.
Оставляем типовые роли в конфигурации без изменений для тех пользователей, которые должны видеть регистр.
Создаем копии нужных ролей (например, копируем роль МенеджерПоПродажам в новую роль МенеджерПоПродажамБезЦен).
В скопированных ролях снимаем права Чтение и Просмотр для регистра ЦеныНоменклатуры.
Назначаем пользователям только урезанные роли, исключая пересечение с типовыми разрешающими ролями.

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

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


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

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ЦеныНоменклатурыСрезПоследних.Цена КАК Цена
    |ИЗ
    |	РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, Номенклатура = &Номенклатура) КАК ЦеныНоменклатурыСрезПоследних";

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

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

Способ 3. Интерфейсное скрытие цен без отключения чтения

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

Оставляем право Чтение включенным в ролях, но снимаем галочку Просмотр для ресурса Цена регистра и колонок документов.
В обработчике формы (например, ПриОткрытии или ПриСозданииНаСервере) проверяем доступность специализированной роли через метод РольДоступна() или функцию ПравоДоступа():


Если Не РольДоступна("ПросмотрКоммерческойИнформации") Тогда
    Элементы.ТоварыЦена.Видимость = Ложь;
    Элементы.ТоварыСумма.Видимость = Ложь;
КонецЕсли;

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