Как в 1С:Бухгалтерии предприятия ПРОФ ограничить доступ к счетам покупателей только своими документами?

← На главную

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

Ограничения типового функционала конфигурации

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

Вариант 1. Установка фиксированного отбора в динамическом списке формы

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

Разберем по шагам порядок реализации:

Создадим расширение конфигурации и добавим в него пустую роль, например ОграничениеПоОтветственному. Назначим эту роль целевым пользователям через профили групп доступа.
Добавим в расширение форму списка документа «Счет на оплату покупателю».
В модуле формы переопределим обработчик события ПриСозданииНаСервере с помощью директивы &НаСервере и метода после вызова типового кода.

Посмотрим на пример программного кода, устанавливающего отбор по текущему пользователю:


&НаСервере
Процедура Отборы_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
    
    Если РольДоступна("ОграничениеПоОтветственному") Тогда  
        ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка(
            Список,
            "Ответственный",
            Пользователи.ТекущийПользователь(),
            ВидСравненияКомпоновкиДанных.Равно,
            ,
            Истина
        ); 
    Иначе
        ОбщегоНазначенияКлиентСервер.УдалитьЭлементыГруппыОтбораДинамическогоСписка(Список, "Ответственный");
    КонецЕсли;    
    
КонецПроцедуры

В этом коде функция ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбораДинамическогоСписка устанавливает жесткий отбор по полю Ответственный, где значением выступает Пользователи.ТекущийПользователь(). Параметр со значением Истина в конце блокирует пользователю возможность отключить этот отбор в стандартных настройках списка.

Обратите внимание на уязвимости данного подхода:

Чужие документы продолжают находиться через стандартный глобальный поиск программы.
Пользователь может открыть чужой счет по прямой навигационной ссылке вида e1cib/... или через структуру подчиненности связанных документов.
Данные остаются доступными в стандартных отчетах (например, через «Универсальный отчет»), если у пользователя есть к ним доступ.
Аналогичный отбор необходимо дублировать не только в форме списка, но и в форме выбора счетов, иначе документы будут видны при подборе.

Вариант 2. Комплексная защита без использования механизма RLS

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

Разберем по шагам необходимые доработки:

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

Вариант 3. Использование механизма ограничений на уровне записей (RLS) в расширении

Рассмотрим подробнее наиболее фундаментальное решение, исключающее утечку информации на уровне запросов к базе данных. Механизм расширений платформы «1С:Предприятие 8.3» позволяет внедрять собственные роли с шаблонами RLS.

Разберем последовательность действий:

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

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