В типовой конфигурации «1С:Бухгалтерия предприятия 3.0» (БП 3.0) разработчики применили упрощенную модель прав доступа. В отличие от более сложных систем, таких как ERP, здесь роли часто сгруппированы по функциональным участкам. Например, роль «Бухгалтер по банку» дает доступ сразу ко всем банковским документам. Часто возникает задача ограничить права более точечно: разрешить пользователю работать с Авансовыми отчетами, но полностью запретить доступ к Ведомостям на выплату зарплаты. Рассмотрим, какими способами можно реализовать такое разграничение, проанализируем их плюсы, минусы и технические нюансы.
В БП 3.0 роли являются «суммарными». Если мы добавим пользователю стандартный профиль доступа, он получит права на целую группу объектов. Попытка просто убрать роль может привести к тому, что пользователь потеряет доступ к важным сопутствующим функциям. Разберем основные пути решения этой проблемы, от административных до программных.
Это наиболее корректный и архитектурно правильный метод. Чтобы не снимать основную конфигурацию с поддержки, мы воспользуемся механизмом расширений. Проанализируем последовательность действий:
АвансовыйОтчет и ВедомостьНаВыплатуЗарплаты).ЧтениеАвансовыхОтчетов и ЧтениеВедомостейНаВыплатуЗарплаты.После создания таких ролей в расширении, нам необходимо перенастроить профили групп доступа. Рассмотрим важный момент: в типовом профиле нужно будет отключить «общую» роль, которая дает доступ ко всем документам участка, и вместо нее добавить наши новые точечные роли. Таким образом, мы получаем гибкий конструктор прав без изменения кода основной конфигурации.
Иногда создание десятков новых ролей кажется избыточным, особенно если нужно просто запретить открытие форм конкретных документов. В этом случае рассмотрим использование подписки на событие ОбработкаПолученияДанныхФормы. Этот метод позволяет «перехватить» момент, когда система пытается получить данные для отрисовки формы документа.
Выясним причину выбора именно этого события: оно срабатывает в менеджере объекта и позволяет программно подменить форму или вызвать отказ в получении данных. Посмотрим на пример реализации логики в модуле расширения или в общем модуле:
Процедура ПриПолученииДанныхФормыДокумента(Источник, ВидФормы, Параметры, ВыбраннаяФорма, ДополнительныеПараметры, СтандартнаяОбработка) Экспорт
// Проверяем, является ли текущий пользователь ограниченным в правах
Если Не РольДоступна("ПолныеПрава") Тогда
// Если это форма документа, к которому мы хотим закрыть доступ
ИмяДокумента = Источник.Метаданные().Имя;
Если ИмяДокумента = "ВедомостьНаВыплатуЗарплаты" Тогда
СтандартнаяОбработка = Ложь;
// Подменяем форму на пустую или вызываем исключение
ВызватьИсключение "Недостаточно прав для просмотра данного вида документов!";
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Важно понимать: данный метод является скорее «интерфейсным костылем». Он эффективно блокирует открытие формы для обычного пользователя, но данные документа все равно остаются доступными в базе. Проницательный пользователь сможет увидеть суммы и даты через универсальный отчет или консоль запросов, так как само право Чтение на уровне метаданных не ограничено.
Для правильной настройки важно различать эти понятия, так как они часто путают начинающих администраторов 1С. Разберем их суть:
В БП 3.0 штатный механизм RLS работает преимущественно по организациям. Настроить RLS по «Видам документов» штатными средствами (галочками) невозможно — это потребует глубокой переработки шаблонов ограничений в коде.
Проанализируем ситуацию, о которой часто забывают при настройке прав. Даже если вы полностью закрыли доступ к форме документа ВедомостьНаВыплатуЗарплаты, данные о выплатах могут быть видны в Оборотно-сальдовой ведомости (ОСВ) по счету 70.
Выясним, почему это происходит. Почти все документы в БП 3.0 делают записи в единый регистр бухгалтерии Хозрасчетный. Если у пользователя есть роль с правом на чтение этого регистра (а она есть почти у всех бухгалтеров для работы с отчетами), он увидит проводки. В проводках часто содержится вся ключевая информация: сумма, подразделение и даже конкретный сотрудник в субконто.
Поэтому, ограничивая доступ к видам документов, всегда учитывайте следующее:
Просмотр отвечает за видимость объекта в интерфейсе и возможность открыть форму. Право Чтение отвечает за возможность системы (и отчетов) прочитать данные из таблиц базы данных.Рассмотрим финальный алгоритм выбора решения. Если ваша цель — строгая безопасность, необходимо создавать новые роли в расширении, отключать типовые широкие роли и внимательно проверять права на регистры накопления и бухгалтерии. Если ваша цель — удобство интерфейса (чтобы лишние документы не мешались под рукой), достаточно использовать подписки на события или просто скрыть пункты меню в настройках навигации.
Помните, что любые изменения в системе прав доступа должны тщательно тестироваться под учетной записью с ограниченными правами, чтобы убедиться в отсутствии «дыр» через стандартные бухгалтерские отчеты.