Как правильно настроить проверку ролей и значений перечисления при записи документа в 1С

← На главную

При разработке бизнес-логики в 1С:Предприятие часто возникает задача ограничить доступ к определенным операциям в зависимости от прав пользователя. Типичный пример: запретить выбор конкретного значения в документе, если у пользователя нет специальной роли. Начинающие разработчики часто сталкиваются с трудностями при написании условий, путая синтаксис сравнения перечислений и логические операторы. Разберем детально, как реализовать такую проверку правильно и красиво.

Анализируем исходную задачу

Представим ситуацию: в документе есть реквизит ВидОперации, который принимает значения из перечисления (например, "А", "Б", "В"). Нам нужно реализовать следующую логику:

Если у пользователя нет специальной роли, он не может выбрать операцию "А".
Если у пользователя есть роль, он может выбирать любую операцию ("А", "Б" или "В").

Рассмотрим по шагам, как избежать ошибок и построить надежное условие в модуле объекта документа.

Разбор типичных ошибок: Перечисление — это не Булево

Одной из самых частых ошибок является попытка сравнить значение перечисления с логическим значением Истина или Ложь. Проанализируем ошибочный код:


// ОШИБОЧНЫЙ КОД
Если НЕ Перечисления.ВидыОпераций.А = Истина Тогда 
    // Так делать нельзя!
КонецЕсли;

Выясним причину ошибки: значения перечислений в 1С являются объектами ссылочного типа. Они не могут быть "истинными" или "ложными" сами по себе. Ссылка на значение перечисления может быть либо равна другой ссылке, либо нет. Правильное сравнение всегда выглядит так: РеквизитДокумента = Перечисления.ИмяПеречисления.ИмяЗначения.

Еще одна ловушка — обращение к менеджеру перечисления вместо конкретного реквизита. Код Перечисления.ВидыОпераций <> Перечисления.ВидыОпераций.А также не имеет смысла, так как вы пытаетесь сравнить всю совокупность метаданных с одной конкретной ссылкой.

Реализация логики проверки прав

Теперь перейдем к правильному построению условия. Нам нужно проверить два факта одновременно: отсутствие роли и выбор запрещенного значения. Проанализируем итоговый вариант решения задачи в обработчике ПередЗаписью:


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

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

Посмотрим на это условие внимательнее. Если РольДоступна() возвращает Ложь И при этом в поле ВидОперации выбрано значение СписаниеЗадолженности, система установит флаг Отказ = Истина. Во всех остальных случаях (если роль есть ИЛИ выбрана другая операция) запись будет разрешена.

Улучшаем взаимодействие с пользователем

Использование метода Сообщить() — это базовый вариант, но в современных конфигурациях (особенно на управляемых формах) лучше использовать объект СообщениеПользователю. Это позволит "привязать" ошибку к конкретному полю на форме, что сделает интерфейс более дружелюбным. Разберем, как это сделать:


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

Важные рекомендации по архитектуре

Рассмотрим несколько продвинутых советов, которые помогут сделать ваш код более профессиональным:

Проверка на сервере: Всегда размещайте подобные проверки в модуле объекта (серверный код). Проверки в модуле формы легко обойти программным кодом, тогда как ПередЗаписью в модуле объекта сработает в любом случае.
Обмен данными: Если вы планируете загружать документы из внешних систем, добавьте проверку Если ОбменДанными.Загрузка Тогда Возврат; КонецЕсли; в начало обработчика. Это предотвратит блокировку записи исторических данных, которые могли быть созданы до введения ограничений.
Использование RLS: Если ограничений становится слишком много, проанализируйте возможность использования механизма RLS (Record Level Security). Это позволит настроить права на уровне платформы, и пользователю даже не будут предлагаться недоступные значения в выпадающем списке.
Кэширование ролей: Функция РольДоступна() работает быстро, но если вы проверяете множество условий в цикле, рассмотрите возможность получения списка ролей один раз при начале сеанса и сохранения их в параметрах сеанса или функциональных опциях.

Таким образом, мы выяснили, что секрет успеха заключается в четком понимании типов данных (ссылка на перечисление — это не число и не булево) и аккуратном использовании логического оператора И для связки проверки прав и значений реквизитов. Следуя этим правилам, вы сможете создавать надежные и понятные системы контроля доступа в ваших решениях на базе 1С.