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

← На главную

При разработке на платформе 1С часто возникают задачи ограничения доступа к объектам: документам, элементам справочников или формам. Зачастую начинающие разработчики сталкиваются с трудностями при написании сложных логических выражений, особенно когда необходимо добавить несколько «исключений» для разных пользователей. Разберем, как работают такие условия и как сделать код чистым, читаемым и профессиональным.

Анализ логики: оператор НЕ и группа условий ИЛИ

Рассмотрим часто встречающуюся конструкцию, которая вызывает вопросы у разработчиков:


Если НЕ (Пользователь = Инициатор
    ИЛИ Пользователь = Ответственный
    ИЛИ Пользователь = СпециальныйПользователь) Тогда
    // Действия при отсутствии прав
КонецЕсли;

Многие ошибочно полагают, что оператор НЕ относится только к первому условию. Однако, согласно правилам алгебры логики, НЕ распространяется на всё выражение в скобках. Если мы «раскроем скобки» (используя законы де Моргана), логика станет гораздо прозрачнее:


Если Пользователь <> Инициатор
    И Пользователь <> Ответственный
    И Пользователь <> СпециальныйПользователь Тогда
    // Отказ в доступе
КонецЕсли;

Таким образом, условие срабатывает (вызывает отказ), если текущий пользователь не является никем из перечисленных. Если хотя бы одно из равенств истинно, блок внутри Если не выполняется, и доступ предоставляется.

Почему хардкодинг имен пользователей — плохая практика?

В приведенном коде автор использует поиск пользователя по наименованию (например, «Пользователь Ирина»). Это несет ряд рисков:

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

Как реализовать проверку прав правильно?

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

1. Использование Ролей

Вместо проверки конкретных имен пользователей, лучше всего создать отдельную Роль (например, «ПолныйДоступКДокументам»). В свойствах этой роли установите права на чтение или изменение нужных документов. Тогда проверка в коде будет выглядеть гораздо лаконичнее:


Если ПравоДоступа("Чтение", Метаданные.Документы.ТвойДокумент) Тогда
    // Доступ разрешен через роль
КонецЕсли;

2. Группы доступа (БСП)

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

3. Использование Регистров сведений

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


Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ ПЕРВЫЕ 1 1 ИЗ РегистрСведений.ОтветственныеЗаДокументы ГДЕ Пользователь = &Пользователь";
Запрос.УстановитьПараметр("Пользователь", ТекущийПользователь);
Результат = Запрос.Выполнить();
Если Не Результат.Пустой() Тогда
    // Пользователь найден в регистре, разрешаем доступ
КонецЕсли;

Заключение: подводим итоги

Итак, мы разобрали, как работает логическое «НЕ» с несколькими условиями. Главное, что стоит вынести из этого урока: избегайте жесткого написания имен пользователей в коде программы. Переход на Роли или Регистры сведений сделает вашу конфигурацию надежной, безопасной и легкой в поддержке. Не бойтесь перестраивать архитектуру доступа — это инвестиция в стабильность вашего проекта.