Как ограничить доступ к отчету в расширении 1С, если у пользователей есть полные права?

← На главную

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

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

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

Почему стандартный механизм ролей не работает?

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

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

Давайте по шагам разберем, как обойти это ограничение платформы.

---

Решение №1. Использование функциональных опций непосредственно в расширении

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

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

Добавим в наше расширение новую константу, например, Расш_ДоступРазрешен с типом значения Булево.
Создадим в расширении объект Функциональная опция (назовем ее Расш_ИспользоватьСекретныйОтчет). В качестве источника выберем созданную константу.
Перейдем на вкладку «Состав» нашей функциональной опции и установим флаг напротив нашего отчета (или его команды) из расширения.
Теперь нам необходимо управлять значением константы в зависимости от того, какой пользователь авторизовался в системе. Сделаем это при начале работы системы.

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


// В расширении заимствуем ПараметрыСеанса и добавляем свой параметр Расш_ДоступКОтчетуРазрешен (тип Булево)
// В модуле сеанса расширения прописываем установку этого параметра
Процедура УстановкаПараметровСеанса(ТребуемыеПараметры)
    
    Если ТребуемыеПараметры.Найти("Расш_ДоступКОтчетуРазрешен") <> Неопределено Тогда
        
        ТекущийПользовательИнфо = ПользователиИнформационнойБазы.ТекущийПользователь();
        // Указываем имя пользователя, которому разрешен доступ
        Если ТекущийПользовательИнфо.Имя = "ИвановИИ" Тогда
            ПараметрыСеанса.Расш_ДоступКОтчетуРазрешен = Истина;
        Иначе
            ПараметрыСеанса.Расш_ДоступКОтчетуРазрешен = Ложь;
        EndIf;
        
    КонецЕсли;
    
КонецПроцедуры

При таком подходе платформа сама скроет команду отчета из всех панелей интерфейса для всех пользователей, кроме Иванова И.И., независимо от наличия у них роли ПолныеПрава.

---

Решение №2. Интеграция с подсистемой БСП «Подключаемые отчеты и обработки»

Если ваша конфигурация разработана на базе Библиотеки стандартных подсистем (БСП) (к таким относятся ERP, КА, УТ, БП, ЗУП), мы можем задействовать стандартный механизм программного формирования команд. Это позволит нам полностью контролировать вывод команды отчета в интерфейс разделов.

Разберем по шагам этот программный метод:

Откроем свойства нашего отчета в расширении и снимем флаг Использовать стандартные команды. Это важнейший шаг: теперь отчет гарантированно не появится в интерфейсе автоматически.
Включим отчет в заимствованную подсистему ПодключаемыеОтчетыИОбработки.
В модуле менеджера нашего отчета в расширении переопределим процедуры интеграции с БСП. Нам понадобятся методы ПриОпределенииНастроек и программное добавление команд.

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


// Модуль менеджера отчета в расширении

Процедура ПриОпределенииНастроек(Настройки, ОбщиеПараметры) Экспорт
    
    // Настройки интеграции отчета с БСП
    Настройки.ВыводитьВПомощниках = Ложь;
    
КонецПроцедуры

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

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

---

Решение №3. Программная защита «второго рубежа» (ПриСозданииНаСервере)

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

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

Выполним следующие действия:

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

Давайте проанализируем пример надежной проверки:


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

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

---

Решение №4. Динамическое управление видимостью на заимствованных формах

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

В этом случае нам нужно заимствовать целевую форму в наше расширение и управлять видимостью кнопки динамически при открытии.

Выполним это по шагам:

Добавим форму документа в расширение.
Добавим на форму нашу команду и кнопку для открытия отчета. Назовем кнопку Расш_ОткрытьСекретныйОтчет.
Создадим обработчик события формы ПриОткрытии с аннотацией &После.

Рассмотрим пример кода:


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

&НаСервереБезКонтекста
Функция Расш_ПроверитьДоступНаСервере()
    
    // Простая и быстрая проверка
    Возврат Пользователи.ТекущийПользователь().Наименование = "Иван Иванов";
    
КонецФункции

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

---

Решение №5. Альтернативный вариант без изменения кода: «Дополнительные отчеты и обработки»

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

Выполним настройку в режиме «1С:Предприятие» под учетной записью администратора:

Сохраним наш отчет из конфигуратора как внешний отчет (файл с расширением .erf).
Перейдем в раздел НСИ и администрирование -> Печатные формы, отчеты и обработки -> Дополнительные отчеты и обработки.
Нажмем кнопку «Добавить из файла» и выберем наш сохраненный файл отчета.
В карточке настройки отчета обратим внимание на таблицу размещения. Назначим отчет в нужные разделы командного интерфейса.
Самое главное: перейдем к настройке быстрого доступа. В списке пользователей отметим флажками только тех сотрудников, которым разрешен запуск этого отчета.

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

---

Подведем итоги

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

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