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

← На главную

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

Метод 1. Управление видимостью на уровне формы

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

Разберем пример кода для управляемой формы, который нужно разместить в процедуре ПриСозданииНаСервере:


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

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

Метод 2. Использование RLS (Record Level Security) на уровне полей

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

Выясним, как правильно настроить RLS для нашей задачи:

Откроем роль, которая дает право на чтение документа (например, «Пользователь»).
Перейдем к объекту (документу) и найдем право Чтение.
В списке полей выберем конкретный реквизит (например, НазначениеПлатежа).
В окне ограничений доступа добавим условие.

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


ГДЕ ВидОперации <> ЗНАЧЕНИЕ(Перечисление.ВидыОперацийСписаниеДенежныхСредств.ПеречислениеЗаработнойПлатыРаботнику)
ИЛИ РольДоступна("СпецРоль")

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

Метод 3. Функциональные опции

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

Рассмотрим алгоритм настройки:

Создадим новую Функциональную опцию (например, ВидетьЗарплатныеДанные).
В качестве Хранилища выберем константу или параметр сеанса.
В состав опции включим нужный реквизит документа.

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

Метод 4. Архитектурное решение: Разделение данных

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

Посмотрим, как это работает:

Удаляем секретный реквизит из основного документа.
Создаем регистр сведений ДополнительныеДанныеДокументов, где измерением будет документ, а ресурсом — наше секретное поле.
Настраиваем RLS на весь этот регистр, разрешая доступ только одной специальной роли.

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


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

Резюме и рекомендации

Подведем итоги нашего анализа. Для решения задачи «скрыть реквизит при определенном условии» у нас есть три пути:

Простой (Интерфейсный): Использовать событие ПриСозданииНаСервере. Подходит для быстрого решения, когда риск утечки данных через отчеты минимален.
Надежный (Платформенный): Настройка RLS на уровне полей. Требует тщательной ревизии всех ролей пользователя (нужно убрать «Полные права» и настроить ограничения в каждой роли).
Профессиональный (Архитектурный): Вынос данных в отдельный регистр с жестким ограничением прав. Это гарантирует безопасность и высокую производительность системы.

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