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