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