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

Программист 1С v8.3 (Обычные формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

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

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

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

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

Для гарантированного отключения доступа к объекту стандартными средствами необходимо:

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

Ограничение доступа к счетам через механизм RLS

Если пользователю требуется предоставить доступ к отчету (например, оборотно-сальдовой ведомости), но скрыть от него обороты и остатки по конкретным счетам (например, 20 или 79), типового отключения прав на отчет недостаточно. В этом случае применяют механизм ограничения прав на уровне записей (RLS).

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

Посмотрим на пример ошибки, которая вызывает системное сообщение «Ожидается выражение "Выбрать"»:

ТекущаяТаблица ГДЕ (НЕ ТекущаяТаблица.Ссылка В (ВЫБРАТЬ ...))

Выясним причину ошибки: конструкция с указанием таблицы допустима только внутри шаблонов RLS (#Шаблон). При прямом задании ограничения на чтение для объекта ПланСчетов текст запроса должен начинаться сразу с условия ГДЕ или предиката.

Посмотрим на корректный синтаксис условия RLS для ограничения чтения счетов с использованием проверки иерархии:


ГДЕ НЕ Ссылка В ИЕРАРХИИ (
    ВЫБРАТЬ ЗапрещенныеСчета.Счет 
    ИЗ РегистрСведений.НедоступныеСчета КАК ЗапрещенныеСчета 
    ГДЕ ЗапрещенныеСчета.Пользователь = &ТекущийПользователь
)

Важно помнить следующие особенности работы RLS с бухгалтерскими данными:

  1. Для проверки подчиненных субсчетов следует использовать оператор В ИЕРАРХИИ, а не сравнение строк через ПОДОБНО, так как строковые операции в RLS существенно снижают производительность базы данных.
  2. Параметры сеанса (например, &ТекущийПользователь) должны быть обязательно инициализированы в процедуре УстановкаПараметровСеанса модуля сеанса, иначе обращение к данным вызовет критическую ошибку.
  3. Ограничения только на объект ПланСчетов недостаточно: отчеты обращаются к виртуальным таблицам объекта РегистрБухгалтерии. Ограничение RLS необходимо дублировать на регистр бухгалтерии по измерениям Счет, СчетДт и СчетКт, иначе в отчетах появятся ошибки доступа либо строки с надписью «Объект не найден».

Программный запрет выбора и формирования отчета по счету

Если внедрение RLS избыточно или нежелательно из-за нагрузки на систему, ограничение можно реализовать программно на уровне формы отчета.

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


Процедура ДействияФормыОсновныеСформировать(Кнопка)
    
    Если РольДоступна("ИнтернетСклад2") И Счет = ПланыСчетов.Хозрасчетный.РасчетыПоВыделенномуИмуществу Тогда
        Предупреждение("У вас нет прав на формирование отчета по выбранному счету!");
        Возврат;
    КонецЕсли;
    
    ОбновитьОтчет();
    
КонецПроцедуры

Разберем еще один надежный способ — ограничение на этапе выбора счета в поле формы через событие НачалоВыбора:


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

Такой подход исключает некорректную подмену одного счета другим, четко оповещает пользователя о правилах доступа и не требует сложной перенастройки прав на уровне СУБД.

← На главную