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