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