Как ограничить доступ к начислениям и строкам табличных частей по категории должности в 1С

← На главную

В практике разработки и администрирования зарплатных решений на платформе 1С часто возникает задача гибкого разграничения прав доступа. Например, требуется разрешить сотрудникам кадровой службы или HR просматривать и редактировать начисления позиций штатного расписания и сотрудников только для категории должности «Рабочие», полностью закрыв доступ к окладам и надбавкам руководящего и инженерно-технического состава. Разберем, почему штатный механизм RLS не всегда подходит для такой задачи и какими практическими методами ее можно решить.

Ограничения платформенного механизма RLS

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

Отсутствие фильтрации отдельных строк табличных частей: Механизм RLS платформы оперирует объектами целиком (документ, элемент справочника). Если задать условие на основе данных табличной части, система проверяет условие для всего объекта. В результате документ либо будет прочитан полностью со всеми строками, либо к нему будет целиком заблокирован доступ с ошибкой нарушения прав. Скрыть конкретные строки внутри открытого документа через RLS невозможно.
Ограничение на уровне полей (Field-Level Security): Платформа позволяет ограничить доступ к отдельным колонкам или реквизитам. Однако типовые управляемые формы конфигураций (ЗУП, ERP, КА) при открытии считывают объект целиком через основной реквизит формы Объект. Обращение формы к закрытому по RLS полю немедленно вызовет системное исключение «Нарушение прав доступа».
Сложная структура хранения данных: В зарплатных конфигурациях плановые начисления регистрируются не только в табличных частях документов, но и пишутся в периодические независимые регистры сведений (например, плановые начисления, значения показателей). Попытка настроить RLS только на регистры при открытых документах приведет к невозможности корректного проведения и рассинхронизации данных.
Просадка производительности СУБД: Если попытаться динамически соединять сложные таблицы для вычисления категории должности «на лету» в запросах RLS, СУБД будет выполнять тяжелые подзапросы на каждую строчку динамических списков, что приведет к блокировкам и существенному замедлению работы всех пользователей.

Вариант 1. Организационное разделение через типовой RLS

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

В таком случае достаточно включить типовое ограничение доступа на уровне записей Библиотеки стандартных подсистем (БСП) по видам доступа Подразделения или Группы физических лиц. Пользователю HR назначаются права только на те подразделения, где числятся рабочие. Это наиболее надежный, оптимизированный и устойчивый к обновлениям конфигурации способ.

Вариант 2. Гибридный подход: контроль записи на сервере и сокрытие в формах

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

Шаг 1. Контроль записи на стороне сервера

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

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


Процедура ПроверитьПраваНаИзменениеНачисленийПередЗаписью(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
    Если Отказ ИЛИ Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;
    
    // Проверяем наличие специальной роли у текущего пользователя
    Если РольДоступна("КадровикБезДоступаКРуководству") Тогда
        Для Каждого Стр Из Источник.Начисления Цикл
            Если Стр.Должность.КатегорияДолжности <> Перечисления.КатегорииДолжностей.Рабочие Тогда
                // Проверяем, менялись ли данные по запрещенной строке
                Отказ = Истина;
                ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
                    "У вас нет прав на изменение начислений для категории должности: " + Стр.Должность.КатегорияДолжности,
                    Источник,
                    "Начисления[" + Формат(Стр.НомерСтроки - 1, "ЧГ=0") + "].Размер"
                );
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

Шаг 2. Сокрытие данных в интерфейсе форм

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

Посмотрим на пример программной настройки условного оформления для таблицы формы:


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

Шаг 3. Блокировка обходных путей в отчетах

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

Ограничить пользователю доступ к стандартной роли АдминистраторСистемы и роли РежимВсеФункции (Режим технического специалиста), чтобы исключить открытие консолей запросов.
Запретить право на использование обработки УниверсальныйОтчет.
Для типовых зарплатных отчетов на СКД скорректировать доступные варианты либо переопределить вывод данных в привилегированных модулях, отсекая конфиденциальные суммы перед формированием результата.

Вариант 3. Архитектурный перенос конфиденциальных данных

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