В конфигурации 1С:Документооборот 8 КОРП часто возникает задача разграничения прав доступа не только на уровне целых документов, но и на уровне отдельных полей (реквизитов) формы. Типовая ситуация: на разных этапах согласования разные участники процесса должны иметь доступ на редактирование только «своих» данных, при этом не имея возможности менять информацию, внесенную коллегами на предыдущих шагах.
Важно понимать ключевое отличие: в 1С:Документооборот существуют роли конфигурации (прописанные в Конфигураторе) и роли исполнителей (элементы справочника, используемые в бизнес-процессах). Стандартная функция платформы РольДоступна() проверяет только роли конфигурации и совершенно «не видит» роли исполнителей, назначенные пользователям в пользовательском режиме. Рассмотрим подробнее, как решить эту задачу различными методами.
Если нам необходимо жестко прописать логику в коде формы, мы должны обратиться к регистру сведений, где хранится информация о соответствии пользователей и их ролей. Проанализируем ситуацию: данные о том, какой пользователь какую роль исполняет, находятся в регистре ИсполнителиРолейИДелегаты.
Разберем пример кода, который можно разместить в модуле формы документа (желательно в процедуре ПриСозданииНаСервере):
&НаСервере
Процедура ОграничитьДоступПоРолиИсполнителя()
ТекущийПользователь = Пользователи.АвторизованныйПользователь();
РольНачальникСбыта = Справочники.РолиИсполнителей.НайтиПоНаименованию("Начальник отдела сбыта");
Если РольНачальникСбыта.Пустая() Тогда
Возврат;
КонецЕсли;
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1
| Исполнители.ИсполнительДелегат
|ИЗ
| РегистрСведений.ИсполнителиРолейИДелегаты КАК Исполнители
|ГДЕ
| Исполнители.ИсполнительДелегат = &Пользователь
| И Исполнители.РольПользователь.Владелец = &Роль";
Запрос.УстановитьПараметр("Пользователь", ТекущийПользователь);
Запрос.УстановитьПараметр("Роль", РольНачальникСбыта);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
// Если пользователь входит в роль, скрываем или блокируем реквизиты
Элементы.СуммаДокумента.Доступность = Ложь;
Элементы.СрокИсполнения.Видимость = Ложь;
КонецЕсли;
КонецПроцедуры
Важный нюанс: обращение к элементам справочника по наименованию (НайтиПоНаименованию) считается плохим тоном в разработке, так как пользователь может изменить название в интерфейсе, и код перестанет работать. Профессиональнее использовать предопределенные элементы (если роль создана в конфигураторе как предопределенная) или искать по уникальному идентификатору (GUID).
Разработчики фирмы «1С» уже предусмотрели механизмы для упрощения проверки ролей. Вместо написания прямых запросов к регистрам, мы можем воспользоваться функциями общего модуля РаботаСРолямиИсполнителей. Это сделает код чище и надежнее.
Рассмотрим, как будет выглядеть проверка в этом случае:
&НаСервере
Процедура ПроверитьПраваЧерезAPI()
Пользователь = Пользователи.АвторизованныйПользователь();
РольСбыт = Справочники.РолиИсполнителей.НайтиПоНаименованию("Начальник отдела сбыта");
// Используем встроенную функцию системы
Если РаботаСРолямиИсполнителей.ИсполнительИмеетРоль(Пользователь, РольСбыт) Тогда
Элементы.ГруппаТехническаяИнформация.Видимость = Ложь;
КонецЕсли;
КонецПроцедуры
Преимущество этого метода в том, что системная функция учитывает не только прямое назначение роли, но и настройки делегирования прав, что критически важно для корректной работы документооборота в крупных организациях.
Перед тем как вносить изменения в код, проанализируем штатные возможности 1С:ДО КОРП. Система содержит мощный механизм «Настройка доступности по состоянию». Выясним, как им воспользоваться:
Если ваши роли исполнителей дублируются рабочими группами, вы можете настроить видимость полей без единой строчки кода. Однако, как отмечают опытные пользователи, этот механизм иногда избыточен или не позволяет настроить очень тонкие условия (например, зависимость одного поля от значения другого в реальном времени).
Если реквизиты, доступ к которым нужно ограничить, являются дополнительными реквизитами (настроены в пользовательском режиме), мы можем использовать механизм условий. Разберем ситуацию: в карточке дополнительного реквизита есть вкладка «Видимость и доступность».
Там можно задать условие: «Доступен, если Состояние равно Согласовано». Хотя прямой привязки к роли исполнителя там нет, можно реализовать следующую схему:
Чтобы не снимать конфигурацию с поддержки, крайне рекомендуется вносить все правки через расширения. Проанализируем, как правильно перехватить управление формой:
&После("ПриСозданииНаСервере").
&После("ПриСозданииНаСервере")
Процедура Расш1_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Ваш код проверки роли и управления видимостью
// Выполнится СРАЗУ ПОСЛЕ типового кода 1С,
// что гарантирует приоритет ваших настроек
КонецПроцедуры
Использование аннотации &После критически важно, так как типовые механизмы 1С:ДО часто пересчитывают видимость элементов в самом конце процедуры открытия формы. Если вы напишете свой код в начале, типовой код может «перебить» ваши настройки доступности своими стандартными значениями.
Подведем итог нашему анализу. Выбор метода зависит от сложности задачи:
РаботаСРолямиИсполнителей.ИсполнительИмеетРоль().Помните, что ограничение видимости на форме не является полноценным ограничением прав доступа (безопасности). Если пользователь обладает навыками работы с консолью запросов или внешними обработками, он сможет увидеть данные скрытых полей. Для полноценной защиты данных на уровне базы данных используйте механизм RLS (Record Level Security).