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