Как запретить проведение документа для конкретной роли в 1С:Управление торговлей 10.3?

При настройке прав доступа в конфигурациях на платформе 1С:Предприятие разработчики и администраторы часто сталкиваются с неожиданным поведением: снятие флагов Проведение и Интерактивное проведение у специализированной роли (например, ЗаведующийСкладом) не запрещает пользователю проводить документ, если ему также назначена базовая роль Пользователь. При этом с другой ролью (например, ОператорККМ) проведение может не выполняться, что создает ложное впечатление избирательной работы запретов.

Разберем детально, как устроена система прав доступа в 1С, выясним причину такого поведения и рассмотрим надежные способы ограничить проведение документов для определенных пользователей.

Принцип аддитивности прав в платформе 1С

В платформе 1С:Предприятие права доступа, назначенные пользователю через роли, объединяются по логическому принципу «ИЛИ» (аддитивность прав). Это фундаментальное правило архитектуры системы безопасности платформы:

1. Роли в 1С являются исключительно разрешающими. Ни одна роль в дереве метаданных конфигуратора не может содержать запрещающего действия. Наличие или отсутствие галочки права означает лишь «разрешить действие» или «не предоставлять это разрешение данной ролью».
2. Приоритет разрешения. Если пользователю назначено несколько ролей, и хотя бы в одной из них установлено право на объект (например, Проведение документа ВозвратТоваровПоставщику), платформа предоставит пользователю это право независимо от настроек всех остальных назначенных ему ролей.
3. Роль «Пользователь». В типовых конфигурациях роль Пользователь является базовой и должна содержать минимальный набор прав: запуск программы, чтение базовых классификаторов, доступ к общему интерфейсу и рабочему столу. Если в измененной конфигурации роли Пользователь были выданы права на проведение прикладных документов, то любой пользователь с этой ролью автоматически получит право на проведение.

Почему проведение не работало с ролью «ОператорККМ»: транзитивные права на регистры

Проанализируем ситуацию, когда комбинация ролей ОператорККМ и Пользователь не давала провести документ, а комбинация ЗаведующийСкладом и Пользователь — позволяла. Проведение документа в 1С — это составная операция, требующая комплексного набора прав:

1. Права Проведение и Интерактивное проведение на сам объект метаданных (документ).
2. Права Чтение и Запись на все регистры (накопления, сведений, бухгалтерии), в которые данный документ формирует движения в процедуре ОбработкаПроведения.

Когда у пользователя были назначены роли ОператорККМ и Пользователь, право на сам документ у него присутствовало (из роли Пользователь). Однако документ не проводился, потому что у этих ролей отсутствовали права на запись в специализированные регистры (например, ВзаиморасчетыСКонтрагентами, ПартииТоваровНаСкладах или Закупки). В момент попытки сформировать движения платформа инициировала исключение нарушения прав доступа к регистру.

Когда же пользователю была назначена роль ЗаведующийСкладом, добавились права на складские регистры. В сочетании с правом проведения из роли Пользователь все условия для успешной записи движений были выполнены, и документ провелся без ошибок.

Способ 1. Декомпозиция прав и очистка роли «Пользователь» (рекомендуемый стандарт)

Самое правильное и архитектурно выверенное решение — привести базовую роль в соответствие со стандартами разработки 1С:

1. Откроем дерево метаданных и снимем права Проведение и Интерактивное проведение для документа ВозвратТоваровПоставщику в роли Пользователь.
2. Создадим отдельную атомарную роль, например ПроведениеВозвратовПоставщику, и включим в ней права на проведение данного документа.
3. Назначим созданную роль только тем группам пользователей (например, менеджерам по закупкам), которым эта операция разрешена по регламенту компании.

При таком подходе роль ЗаведующийСкладом останется без прав на проведение возвратов, а базовая роль Пользователь больше не будет несанкционированно раздавать избыточные привилегии.

Способ 2. Программный контроль через подписку на события

Если конфигурация уже снята с поддержки и нет возможности быстро перенастроить профили всех пользователей, применим программное ограничение с помощью подписки на событие. Это позволит не изменять типовые модули самих документов.

Разберем по шагам создание программного запрета:

1. Создадим новую роль ЗапретПроведенияВозвратовПоставщику или используем проверку существующей роли.
2. Создадим новый общий модуль (например, ОграничениеПравСобытия) с установленными флажками Сервер и Внешнее соединение.
3. Создадим объект метаданных Подписка на событие с источником ДокументОбъект.ВозвратТоваровПоставщику и событием ОбработкаПроведения.

Посмотрим на пример обработчика в общем модуле:

Процедура ОбработкаПроведенияЗапретВозвратов(Источник, Отказ, РежимПроведения) Экспорт

    // Проверяем наличие роли, для которой запрещено проведение
    Если РольДоступна("ЗаведующийСкладом") И НЕ РольДоступна("ПолныеПрава") Тогда
        Отказ = Истина;
        ВызватьИсключение "У вас недостаточно прав для проведения документа ""Возврат товаров поставщику"".";
    КонецЕсли;

КонецПроцедуры

Способ 3. Ограничение доступа на уровне записей (RLS)

Если требуется запретить проведение без редактирования программного кода, воспользуемся механизмом RLS (Record Level Security):

1. В конфигураторе перейдем к нужной роли (например, Пользователь или ЗаведующийСкладом).
2. Выберем документ ВозвратТоваровПоставщику и перейдем на право Интерактивное проведение.
3. На вкладке Ограничение доступа на уровне записей зададим условие ограничения. Например, для полного запрета укажем условие:

ГДЕ Ложь

При таком условии право на проведение формально назначено, но физически не применимо ни к одной записи в информационной базе, что делает интерактивное проведение невозможным.

Способ 4. Использование типовых «Дополнительных прав пользователей» в УТ 10.3

В конфигурации «1С:Управление торговлей 10.3» встроен пользовательский механизм тонкой настройки ограничений, не требующий работы в конфигураторе:

1. Перейдем в режим 1С:Предприятие с полными правами.
2. Откроем меню Сервис — Пользователи — Настройка дополнительных прав пользователей.
3. Выберем нужного пользователя или группу пользователей.
4. Настроим доступность прав по редактированию проведенных документов, контролю остатков и проведению документов без контроля.

Диагностика прав доступа

Для точного выяснения причин ошибок проведения и проверки доступных прав у конкретного сеанса используем встроенные инструменты платформы:

1. Журнал регистрации. При возникновении ошибок доступа откроем Журнал регистрации и установим отбор по событию Отказ в доступе. В деталях записи будет четко указано имя регистра или метаданного, к которому заблокирован доступ.
2. Программная проверка прав. В отладчике или внешней обработке выполним методы проверки прав текущего пользователя:

// Проверка права на проведение документа
ПравоНаДокумент = ПравоДоступа("ИнтерактивноеПроведение", Метаданные.Документы.ВозвратТоваровПоставщику);

// Проверка права на запись в регистр партий
ПравоНаРегистр = ПравоДоступа("Запись", Метаданные.РегистрыНакопления.ПартииТоваровНаСкладах);