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