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