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