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