Analyzer 1C — единый граф типовой и расширений плюс инструмент обновления поставки
В крупных внедрениях типовая конфигурация 1С почти всегда дополнена одним или несколькими расширениями. Конфигуратор показывает их раздельно — аналитик вручную сопоставляет, «что фактически работает». Analyzer 1C объединяет типовую и все расширения в единый граф знаний: объекты, модули, функции, права, RLS-условия, подписки, регламенты, обработчики обновления, состав определяемых типов, запросы BSL — всё это видно сразу и снабжено пометкой о происхождении.
В линейке 2.0 анализатор стал ещё и инструментом обновления поставки: сравнивает и объединяет версии конфигурации деревом «как в Конфигураторе», загружает бинарные файлы поставки .cf/.cfe напрямую и находит скрытые конфликты обновления. На примере 1С:ERP. Управление холдингом (28 342 модуля, 699 793 функции, 2 032 роли) инструмент помогает архитектору, аналитику безопасности и разработчику ориентироваться в крупной конфигурации и получать ответы на «межсущностные» вопросы за один клик.
- Сравнение и объединение версий деревом «как в Конфигураторе» с выгрузкой готового плана решений
- Скрытые конфликты обновления: типовую функцию подменяет перехват расширения, висячие ссылки на удаляемые функции
- Сквозные пометки «Доб.» / «Заимств.» / переопределения — виден вклад каждого расширения
- Анализ влияния, запросы BSL, роли и RLS, граф вызовов, циклические зависимости модулей
- 6 форматов загрузки: ZIP-выгрузка, монорепо, отдельные репозитории, EDT-проект, EDT workspace и бинарные
.cf/.cfe
Две версии в одной поставке: Community и полная
Анализатор поставляется в двух вариантах. Community — версия с минимальной стоимостью: полноценный граф одной конфигурации с расширениями, все срезы анализа (дерево типов, карточки объектов и ролей, RLS, параметры сеанса, функциональные опции, граф вызовов, циклы, запросы BSL). Полная версия снимает ограничение на число систем и добавляет инструмент обновления поставки и подключение ИИ-агентов.
Под ограничение в Community попадают именно эти возможности — всё остальное доступно без урезаний. Перейти на полную версию можно в любой момент, не переустанавливая продукт.
Что умеет инструмент
Обновление поставки — главное в линейке 2.0
Анализатор перестал быть только «смотрелкой» графа и стал инструментом обновления. Теперь он сравнивает и объединяет версии конфигурации так же, как штатное «Сравнение и объединение конфигураций» в Конфигураторе, загружает поставку напрямую из бинарных файлов и предупреждает о скрытых конфликтах, которые иначе всплыли бы уже после обновления.
Сравнение версий деревом «как в Конфигураторе»
Раньше сравнение версий показывало плоские списки изменённых объектов и функций. Теперь это дерево по образцу штатного «Сравнения и объединения конфигураций» 1С:
- Тип метаданных — Справочники, Документы, Общие модули, Роли, Регламентные задания и т.д. Общий функционал собран в папку «Общие» вверху, как в дереве типов.
- Конкретный объект — подписан синонимом, с цветным маркером статуса слева: добавлен, удалён или изменён.
- Что изменилось внутри — изменённые функции, реквизиты, формы и макеты. Функция всегда показана внутри своего объекта-владельца, а не отдельным плоским списком.
Дерево занимает треть ширины, окно просмотра изменений — остальное. Сразу видна привычная по Конфигуратору картина «что обновилось» без ручного перебора. Фильтры по категориям (конфликт, обновится само, моё сохранится, новое у вендора, удалено вендором) оставляют в дереве только нужное.
Окно кода: две и три колонки, подсветка BSL
Клик по изменённой функции открывает окно с её телом. В обычном сравнении двух версий — две колонки «моё ↔ эталон», при обновлении поставки — три колонки: Основная, Поставщик и База (трёхсторонняя сверка). Отдельной секцией показаны переопределения функции из расширений.
Код читается как в Конфигураторе: строки не переносятся (горизонтальная прокрутка, как в редакторе модуля), отличия подсвечены построчно, работает подсветка синтаксиса BSL — ключевые слова, комментарии, строки, директивы, числа и даты раскрашены привычными цветами. Внизу — редактируемая панель «Результат объединения», куда складывается итоговый вариант функции.
Рекомендации, решения и выгрузка настроек
Сравнение доведено до полноценного инструмента обновления поставки:
- для каждого изменения анализатор предлагает решение в одном из четырёх режимов Конфигуратора (взять своё, взять из поставки и т.д.), и решение можно переопределить вручную прямо в строке дерева;
- работа над объединением сохраняется на сервере — большое обновление можно вести не один день. При повторном открытии формы анализатор сам возвращает последний выбор версий и продолжает сверку с того же места, с расставленными решениями и правками кода;
- готовый набор решений выгружается файлом настроек для штатного Конфигуратора: один файл на основную конфигурацию плюс по файлу на каждое расширение. Конфигуратор подхватывает его в своём «Сравнении и объединении» и применяет решения автоматически.
Рутинную часть обновления — пройтись по сотням изменений и для каждого выбрать сторону — можно сделать в удобном дереве анализатора, а в Конфигуратор отдать уже готовый план.
Важно. Выгрузка настроек объединения пока в разработке. Используйте её только с обязательной проверкой: перед применением сверяйте предложенные решения и итоговый код в Конфигураторе. Ответственность за корректность объединения и сохранность конфигурации полностью лежит на пользователе.
Скрытый конфликт обновления из-за перехвата расширением
В дереве сравнения такое изменение помечается как конфликт: в подсказке указано, в каком расширении лежит перехват, который нужно пересмотреть перед обновлением.
Опаснее всего при обновлении «тихие» конфликты. Вендор поменял типовую функцию, а в вашей конфигурации эту же функцию подменяет перехват расширения (&Вместо или &ИзменениеИКонтроль). Обновление вендора тогда не вступит в силу, пока не обновлён сам перехват, — но в обычном сравнении это выглядело бы как спокойное «обновится само».
Анализатор распознаёт такой случай и помечает изменение как конфликт, прямо подсказывая, в каком расширении лежит перехват. Исключения учтены: если перехват &Вместо вызывает ПродолжитьВызов() (исполняет и новую логику оригинала) или это доопределение &Перед / &После — подмены нет, и обновление считается обычным, без ложной тревоги.
Проверка висячих ссылок при удалении функции
Если в новой поставке функция удаляется, а в текущей конфигурации на неё ещё ссылаются, после объединения вызовы повисли бы в пустоту. Окно кода теперь это проверяет и показывает предупреждение со списком вызывающих функций (с пометкой, если вызов идёт из расширения).
Анализатор отличает действительно опасные ссылки от безопасных: вызывающие, которые в новой поставке остаются, подсвечены красным — это и есть будущие битые ссылки; те, кого вендор удаляет заодно, показаны приглушённо и зачёркнуто. Если остающихся нет, предупреждение зелёное: можно объединять спокойно.
Загрузка из бинарных .cf / .cfe и циклы зависимостей
Ещё две крупные возможности 2.0: загрузка поставки прямо из бинарного контейнера 1С — без предварительной выгрузки в файлы — и поиск циклических зависимостей между модулями.
Бинарные .cf и .cfe — шестой способ загрузки
Достаточно отдать анализатору сам файл поставки — .cf для конфигураций и .cfe для расширений. Это покрывает и конфигурации-гиганты нового формата (поставки ERP больше гигабайта): такие контейнеры обрабатываются потоково, чтобы не упереться в память. Из бинаря извлекаются объекты метаданных и их состав, общие формы, подписки на события и регламентные задания. Вендорскую поставку теперь можно загрузить как версию и сразу сравнить с текущим состоянием системы.
Циклические зависимости между модулями
Новый раздел анализа — поиск циклов во взаимных вызовах модулей. Циклическая зависимость (модуль А зовёт Б, Б зовёт В, В снова зовёт А) усложняет сопровождение и мешает выносить код. Анализатор находит такие кольца и показывает их графом. Главное — раздел отвечает на вопрос «где и что рвать»: для каждого кольца видно самое слабое звено, разрыв которого проще всего разомкнёт цикл.
Навигация по конфигурации
Интерфейс разделён на две части: слева — дерево навигации и кнопки специализированных экранов (Парам.сеанса, Опред.типы, Крит.отбора, XDTO-пакеты, Обновление ИБ, Функц.опции, Планы ВХ, Конструктор профилей, Анализ функций, Граф вызовов, Изучение подсистем, Внешние API), справа — карточка выбранной сущности. Базовое переключение режима — через вкладки «Подсист.», «Типы», «Роли», «Инфо».
Интерфейс разделён на две части: слева — дерево навигации с переключателем режима, справа — карточка выбранной сущности. Шапка справа показывает иконку и тип объекта, его синоним и маркер расширения (если есть). В дереве слева — имена объектов всегда отображаются синонимами, символьное имя при необходимости мелким серым в скобках; счётчики на каждом узле показывают число сущностей внутри в реальном времени.
Дерево типов
Режим «Типы» группирует все объекты конфигурации по типам метаданных: общие модули, справочники, документы, регистры, отчёты, обработки и т.д. Каждая группа показывает количество объектов; заголовки групп «прилипают» к верху при прокрутке. Объекты типовой и расширений видны в одном списке: маркер Доб. — объект целиком из расширения, Заимств. — типовой, дополненный расширением.
Дерево типов 1С:ERP. Управление холдингом — 28 342 модуля в 20 типах метаданных
Дерево подсистем
Режим «Подсист.» отражает иерархию подсистем конфигурации. Для каждой подсистемы — вложенные подсистемы и типы объектов с количеством. Маркер на объекте — добавлен расширением, — типовой объект, который расширение привязало к своей подсистеме. Это позволяет увидеть, какие расширения затронули каждую подсистему.
Подсистемы ERP УХ с объектами расширения «Управление Лизинговой компании»
Поиск
Мгновенный поиск по всем сущностям одновременно: модули, справочники, документы, роли, подсистемы, параметры сеанса, функциональные опции, XDTO-типы. Поиск идёт по синониму, а не только по символьному имени (Ctrl+Shift+N в Конфигураторе ищет только по имени). Результаты группируются по типам и появляются по мере ввода. Объекты, добавленные или дополненные расширениями, помечены / с именем расширения — сразу видно, что пришло из расширения, а что из основной конфигурации.
Поиск «лизинг» — обычные объекты, заимствованные и устаревшие в одном списке
Возможности анализа: запросы BSL, безопасность и cross-cutting объекты
За последний год Анализатор закрыл весь приоритетный трек cross-cutting объектов 1С — команды объектов и общие команды, параметры сеанса с RLS, обработчики обновления информационной базы, критерии отбора, XDTO-пакеты с визуальным графом связей, определяемые типы и планы видов характеристик. На вершине этого — анализ запросов BSL (фича 10): обратный индекс «кто читает / пишет объект через язык запросов 1С» во всех источниках сразу — модули, формы (динамические списки) и макеты СКД.
Параллельно сложилась единая концепция трёх маркеров расширений, которая работает сквозь все разделы: дерево типов, карточки объектов, роли, параметры сеанса, функциональные опции, XDTO-пакеты, граф вызовов, конструктор профилей. Сценарий аудита безопасности (RLS + привилегированные установки + разделение обязанностей) собран в одном потоке работы. Этот документ — сводный обзор всего, что появилось в текущем релизе.
Анализ запросов BSL — обратный индекс
Вкладка «Запросы» в карточке документа — читатели и писатели в одной таблице
Конфигуратор показывает текст конкретного запроса в момент, когда вы открываете модуль. Но обратный вопрос — «кто читает этот документ в запросах 1С» — стандартными средствами не решается: нужен полнотекстовый поиск по всем модулям, формам и макетам СКД, и потом ручная сверка результатов.
Анализатор парсит все BSL-запросы во время загрузки конфигурации и строит обратный индекс: для каждого объекта (справочника, документа, регистра) известно, в каких функциях, формах и СКД-макетах он участвует как источник или приёмник. В карточке объекта появилась вкладка «Запросы».
Что внутри:
- Читатели — функции, формы и макеты, выбирающие данные этого объекта.
- Писатели — функции, которые записывают в объект.
- Для каждой строки: модуль, строка кода, источник (BSL, макет СКД или динамический список формы), признак СКД-фильтра, индикатор наличия параметров, число соединений в запросе.
- Текст запроса разворачивается рядом со строкой или открывается в отдельном окне.
- Дедупликация рёбер: один и тот же запрос на нескольких источниках агрегируется с указанием числа источников.
Маркеры расширений — те же / применительно к функции, содержащей запрос: видно, что чтение типового объекта идёт из BSL расширения. При обновлении типовой это критично: изменение реквизита типового документа может сломать запрос расширения, который ссылается на этот реквизит по имени.
Кейс. «Удаляем реквизит "СтавкаНДС" из документа "ОтчётКомитенту" — какие запросы конфигурации и расширений сломаются?» Карточка документа → вкладка «Запросы» → разворачиваем текст каждого запроса с reads → ищем упоминания СтавкаНДС в SELECT или WHERE. Если хоть один запрос есть в расширении — это обязательная зона рефакторинга расширения.
Параметры сеанса и точки RLS
Карточка параметра сеанса с RLS-выражениями — четыре секции в одном окне
Анализатор видит параметры сеанса как полноценные узлы графа: где они задаются, кто их читает и где они используются в RLS-выражениях ролей. Это даёт прямой ответ на вопрос «если я изменю обработчик установки параметра X, кому это сломает доступ» — без taint-анализа, чисто из статической картины.
Где смотреть. Кнопка «Парам.сеанса» в левой панели. Слева список всех параметров со счётчиками (типов в составе, BSL-функций, которые пишут и читают, RLS-выражений). Справа — карточка из четырёх секций:
- Состав типов — ссылочные типы и примитивы значения параметра; типы, добавленные расширением, помечены.
- Устанавливают — функции, которые присваивают параметр. Стандартный БСП-обработчик
УстановкаПараметровСеансавыделен красной плашкой PRIV — это привилегированный setter, в котором значение фиксируется на сеанс и подставляется в RLS. - Читают — функции, ссылающиеся на параметр в любых других позициях (правая часть присваивания, условие, текст запроса).
- Используется в RLS — таблица RLS-выражений ролей, где параметр упоминается как
&ИмяилиПараметрыСеанса.Имя. Каждая строка показывает роль, объект, право и полный текст условия — RLS можно прочесть, не открывая роль в EDT.
Масштаб. 1С:ERP. Управление холдингом — 121 параметр сеанса, 305 установок, 767 чтений, 7 002 RLS-выражения в 2 032 ролях. Из них 5 параметров одновременно задаются в УстановкаПараметровСеанса и используются в RLS — то есть ошибка в их установке может тихо изменить поведение RLS-фильтров без предупреждений со стороны платформы. На реальной 1С:ERP. Управление холдингом параметр ОграничениеДоступаНаУровнеЗаписейУниверсально устанавливается в привилегированном режиме функцией УстановкаПараметровСеанса модуля УправлениеДоступомСлужебный и используется в 6 924 RLS-выражениях. Понять «насколько это безопасно» требует архитекторской экспертизы, но сам факт обнаружения такого пути занимает один клик.
Команды объектов и общие команды
Команды объектов в карточке справочника — третья «точка входа» рядом с регламентами и HTTP-сервисами
В графе появился большой класс объектов 1С, до которого раньше анализатор не добирался — команды. И обычные пользовательские команды конкретных объектов («Создать на основании», «Печать счёта», «В отбор»), и общие команды конфигурации (CommonCommands), которые выполняются независимо от формы. Команды — это третья «точка входа» в логику конфигурации рядом с регламентными заданиями и HTTP/Web-сервисами.
Где смотреть.
- В карточке справочника, документа, регистра, отчёта или обработки — вкладка «Команды (N)» рядом со «Связями» и «Функциями». В таблице: имя команды (с синонимом), её группа (
FormCommandBarImportant,CommandGroup.усУстановитьСтатус) и счётчик ролей с правом Use (клик раскрывает список ролей). - В дереве типов слева — ветка «Общие команды N» рядом с «Общие модули» (например, 526 общих команд в 1С:ERP.УХ). В карточке общей команды виден список ролей, которым выдан Use.
Расширения маркируются прямо в строке: — команда добавлена расширением, — типовая команда переопределена расширением. Это закрывает класс вопросов аудита «эту команду добавил лизинг» / «эту команду переопределило Бюро1440».
Парсер ролей раньше выбрасывал имена прав вида <Object>.Command.<X> и CommonCommand.<X> — теперь они корректно резолвятся в рёбра grants к команде-vertex’у. На крупных типовых это десятки тысяч новых рёбер, делающих аудит безопасности полным: 1С:ERP. Управление холдингом — 1 619 команд (включая 41 от расширения «Управление лизингом»).
Карта миграций БСП: обновление ИБ
Обработчики обновления — режим «Между версиями»
Для внедренцев типовых конфигураций. Анализатор видит карту миграций между версиями БСП: полный список обработчиков ОбновлениеИнформационнойБазы.ПриДобавленииОбработчиковОбновления, разнесённый по подсистемам и версиям. Это даёт прямой ответ «что отработает при апгрейде с версии X до Y» — без чтения кода БСП и без запуска тестового обновления.
Где смотреть. Кнопка «Обновление ИБ» в левой панели. Слева список БСП-подсистем (сортировка по числу обработчиков, с поиском). Справа — два режима:
- Все обработчики — таблица, в которой каждая запись массива
Обработчики.Добавить— отдельная строка: версия с цветной подсветкой, процедура в формате<ОбщийМодуль>.<Метод>или<Документы|Справочники|Регистры…>.<Объект>.<Метод>, очередь, режим (Seamless / Deferred / Exclusively), комментарий. Имя процедуры красное с пометкой «unresolved», если функция-реализация отсутствует (сигнал об устаревших обработчиках). Правый клик на резолвленной процедуре — «Открыть в графе вызовов» и «Перейти к связям модуля». - Между версиями — два выпадающих списка «С версии» / «До версии» с числом обработчиков рядом. Результат — точный чек-лист, что отработает при апгрейде, с уже посчитанной очерёдностью. Каждая подсистема БСП имеет независимый таймлайн — это явно подсвечено плашкой, чтобы никто не пытался смешивать версии разных подсистем.
Расширения. Если расширение добавляет собственный общий модуль с процедурой ПриДобавленииОбработчиковОбновления (типичный паттерн отраслевых надстроек), его обработчики попадают в общий список с тегом. На реальной ЕРПУХ + Управление лизингом это 8 дополнительных миграций модуля лиз_ОбновлениеИнформационнойБазы.
Цифры. 1С:ERP. Управление холдингом — 903 обработчика обновления в 117 подсистемах, резолв 98,0 % (885 из 903). Остальные ссылаются на отсутствующие процедуры — кандидаты на чистку устаревших обработчиков.
XDTO-пакеты и критерии отбора
Граф связей XDTO-типа — свойства, атрибуты, фасеты, легенда
XDTO-пакеты — схемы данных Web-сервисов 1С (по сути XSD в формате 1С). Раньше у Web-операции XDTOValueType был просто строкой prefix:Local; теперь это полноценные узлы со своими свойствами и связями. Доступны: список типов пакета (объектные и valueType), наследование, кардинальности свойств, форма (Element / Attribute / Text), список Web-операций, использующих тип, обратная связь «в каких других типах текущий тип используется как тип свойства». Расширения обрабатываются единообразно тремя способами: свой пакет с уникальным targetNamespace, дополнение типового пакета новым типом, дополнение существующего объектного типа новыми свойствами — все три отмечаются маркерами / в карточке.
Кнопка «Граф связей» в карточке типа открывает визуальную карту: дерево раскрывается слева направо лесенкой, каждый узел — отдельная сущность с собственным +/−. Под корнем выбранного типа идут свойства, рядом — кардинальность ([0..1], [1..1], [0..∞]) и имя типа значения. Цветные плашки: голубая — сам XDTO-тип, жёлтая — свойство-элемент, бирюзовая — XML-атрибут, зелёная — Web-операция (со стрелками →/←/ по направлению параметра), серая — фасета valueType (значения, шаблон, длина). Можно «провалиться» в Patch → AppliedFor → SupportedConfiguration без переключения карточек.
Критерии отбора — ещё один cross-cutting объект, теперь самостоятельная вершина графа со своим составом, типом значения и BSL-использованиями. Кнопка «Крит.отбора» в левой панели открывает список со счётчиками ( типов значения, объектов в составе, резолвлено, использований в BSL). Карточка из трёх таблиц: тип значения, состав (полный список путей Document.X.Attribute.Y; элементы расширений маркируются ), использование в BSL (функции с обращением КритерииОтбора.<Имя>). Это упирает критерий в impact-граф изменений.
Перезагрузка обязательна. Все большие фичи добавляют в граф новые коллекции вершин и рёбер. Для систем, загруженных на старых версиях, нужно нажать «Перезагрузить» в шапке системы — иначе соответствующие разделы будут пустыми. Если в системе есть расширения и нужно обновить только ext-вклад, работает «Перезагрузить расширения» — все cross-cutting фичи закрывают ext-only reload корректно: числа vertex и рёбер совпадают с полной загрузкой.
Анализ функций и Граф вызовов
Самая «движковая» часть инструмента: импакт-анализ кода. Граф вызовов BSL построен на основе разбора всех модулей конфигурации и расширений. Рёбра — не только прямые вызовы, но и триггеры записи объектов, подписки на события, регламентные задания, обработчики обновления, RLS-условия и шаблоны ограничений.
Граф вызовов отвечает на вопрос «что случится, если я изменю эту функцию / удалю этот объект / отключу этот регламент». В Конфигураторе аналогичный запрос требует ручного полнотекстового поиска по коду и сверки результатов; в крупной конфигурации он занимает минуты или часы. В Анализаторе тот же запрос — это обход предварительно построенного графа в ArangoDB, и ответ появляется за доли секунды.
В графе видны не только прямые вызовы, но и косвенные — через подписки на события, регламентные задания, переопределения обработчиков в расширениях. Это даёт «полный взрыв» при изменении функции, который штатными средствами вычислить невозможно.
Анализ функций
Левая панель в режиме «Анализ функций» показывает то же дерево типов, но переключатель сверху правой панели — «Все / Пред. и выше / Монстры». Это фильтр по числу вызовов и метрикам функции: «монстр» — функция с одной из четырёх причин: более 500 строк кода, более 50 ветвлений (Если / Пока / Для / Попытка), запросы к БД внутри цикла (N+1), более 10 вызовов .Выполнить в одной функции.
В карточке модуля — таблица функций с колонками: имя, длина, число вызывающих, число вызываемых, флажки динамического вызова, триггеров BeforeWrite/OnWrite/Posting, признак has_dynamic_call (Выполнить/ВызватьМетодОбъекта — статически не раскрывается). Строки текста запросов (начинающиеся с |) исключены из подсчёта: весь текст запроса считается за одну логическую строку и не влияет на оценку сложности.
Граф вызовов от функции
Отдельный режим (кнопка «Граф вызовов» в левой панели). Вы выбираете функцию в дереве или через поиск; справа открывается граф со стрелками calls in (кто вызывает выбранную функцию) и calls out (что выбранная функция вызывает дальше). Граф интерактивный: можно зумировать, двигать узлы, кликать на узел для перехода в его карточку.
В графе видны не только прямые вызовы, но и косвенные: через подписки на события, регламентные задания, переопределения обработчиков в расширениях. Например, удаление документа «Реализация товаров и услуг» в типовой 1С:ERP вызывает не только напрямую упомянутые функции, но и пять подписок «Перед записью» на типе документа — все они появляются в графе как косвенные пути.
В каждом узле графа отображается имя функции, синоним модуля (для общих модулей — имя модуля; для модулей объекта — синоним объекта-владельца), и маркер расширения, если функция или модуль из расширения. Узлы можно фильтровать по типу метаданных и направлению связи.
Точки нагрузки и проблемные модули
Фильтр «Пред. и выше / Монстры» в разделе «Анализ функций» выделяет функции по «массе» в графе вызовов:
- Предупреждение — функции приближаются к опасным значениям: 200–500 строк, 20–50 ветвлений, 5–10 запросов. Изменение такой функции с большой вероятностью ломает существенный объём кода — рисковая зона при обновлении.
- Монстр-функция — самые «нагруженные» функции и модули-гиганты, на которые опирается большая часть конфигурации. Первые кандидаты на рефакторинг и тщательное тестирование при обновлении типовой.
В таблице функций модуля — цветная колонка «Строк» и «Ветв.», колонка «Запросов» с отметкой «N (M в цикле) при N+1». При клике на функцию — правая панель с подробным объяснением: почему именно она попала в монстры и какие числа за этим стоят.
Кейс. Общий модуль «Хозяйственные операции» (НастройкиХозяйственныхОпераций) — функция ПриНачальномЗаполненииЭлементов: 24 266 строк и 991 ветвление. Это первый кандидат на рефакторинг при следующем апгрейде, и видно это до того, как обновление поломает что-то на тестовой ИБ.
Расширения в графе вызовов
Граф объединяет вызовы из типовой и из расширений в одну сеть:
- Доб. <имя расширения> на узле — функция из расширения;
- Заимств. <имя расширения> на узле типовой функции — расширение её «перехватывает» (своя функция-перехватчик типовой через
&Перед,&После,&Вместо); - имя расширения — обработчик регламентного задания или конечной точки HTTP подменён расширением.
Для функций-перехватов считаются эффективные метрики: строки и ветвления самого перехватчика плюс оригинальной функции. Это даёт честную картину реальной нагрузки при поддержке такой связки.
Особенно ценно при обновлении типовой: видно, какие именно функции типовой используются расширениями (рисковая зона при изменении сигнатуры), и какие точки расширения зависят от изменений в типовой. Один взгляд на граф — и понятно, что именно нужно тестировать после апгрейда.
Безопасность — сводный сценарий
Программа не проверяет «правильно ли настроена безопасность» — это решает архитектор по политике организации. Зато программа собирает материал для такого решения: тексты RLS-условий, привилегированные установки параметров сеанса, сводную матрицу прав. Эти материалы разбросаны по разделам «Парам.сеанса», «Роли», «Констр.профилей»; здесь они сведены в общий поток в трёх плоскостях.
RLS — ограничения на уровне записей
Полезные выборки из карточки роли и параметра сеанса:
- Найти роли, у которых дано Изменение на чувствительный справочник без RLS-ограничения — могут менять любую запись.
- Посмотреть текст RLS-условия каждой пары «роль объект» и убедиться, что условие действительно ограничивает данные (а не сводится к
&Истина). - Найти параметры сеанса, на которые опираются RLS-условия — если такой параметр устанавливается в привилегированном режиме без обоснования, это уязвимость.
Текст RLS открывается в один клик по пометке (RLS) рядом с правом — не нужно открывать роль в EDT и листать XML.
Роль «Базовые права БСП»: право «Чтение» справочника с пометкой (RLS), в окне — текст условия (опирается на параметр сеанса)Привилегированный режим — пометка PRIV
УстановитьПривилегированныйРежим(Истина) отключает RLS и проверки прав для блока кода. Используется обоснованно (для системных операций), но злоупотребление превращает любую функцию в потенциальную лазейку обхода прав.
В карточке параметра сеанса строка таблицы «Устанавливают» помечается PRIV, если функция выставляет привилегированный режим непосредственно перед установкой параметра. Это критическая зона аудита, потому что параметр потом используется в RLS-условии — то есть «привилегированная установка → RLS пропускает любые данные».
Привилегированная установка параметра, используемого в RLSКейс. Параметр ОграничениеДоступаНаУровнеЗаписейУниверсально устанавливается в привилегированном режиме функцией УстановкаПараметровСеанса модуля УправлениеДоступомСлужебный и используется в 6 924 RLS-выражениях ролей. Насколько это безопасно — вопрос архитекторской экспертизы, но сам факт обнаружения такого пути занимает один клик.
Разделение обязанностей
В терминах безопасности «разделение обязанностей» (Segregation of Duties, SoD) — это когда в одной роли или одном профиле не должно быть прав, которые позволяют пользователю самому и создать, и одобрить, и исполнить чувствительную операцию. Классический пример: «Добавление документа "СписаниеДенежныхСредств" + Подтверждение оплаты».
Программа не проверяет такие конфликты — у каждой организации своя политика, и формализовать её здесь нельзя. Но программа даёт два материала для ручной или внешней проверки:
- Права каждой роли по объектам — в карточке роли (раздел «Роли»), с пометкой (RLS) у прав с ограничениями.
- Конструктор профилей — предпросмотр суммарных прав до создания профиля. Если в сводных правах профиля обнаружен объект, на который даётся Удаление, — это повод обсудить такое право с заказчиком до того, как профиль создан.
Связь с расширениями
Аудит безопасности обязан учитывать расширения. Часто именно в расширениях, написанных без оглядки на типовую политику доступа, появляются УстановитьПривилегированныйРежим там, где их не было.
Маркер у строки таблицы «Устанавливают» или «Читают» немедленно подсказывает: «это расширение, его правит ваша команда — проверьте обоснование».
Сценарий. «Проверить, не появилось ли в расширении нового PRIV-вызова поверх типового параметра». В карточке параметра сортируем «Устанавливают» по маркеру — видим только установщики из расширений. Если среди них есть строка с PRIV — это новая привилегированная установка, которой нет в типовой; её обоснование нужно документировать.
Расширения видны везде — три маркера
В реальном внедрении вопрос «что фактически работает» — это типовая плюс расширения, а не отдельные сущности. Без сквозной подсветки вкладов расширений аналитик тратит на каждое расследование десятки минут «открыть расширение отдельно, найти, сопоставить». Сквозные пометки / / снимают этот налог.
«Доб. имя расширения» — золотистый
Сущность создана расширением целиком. Своя роль, своя подписка, своя функциональная опция, свой регламент, свой параметр сеанса, свой XDTO-пакет, своя команда. В дереве слева помечается значком в строке объекта; в карточке справа — крупный тег в заголовке.
Подписка «Отмена проведения цепочки документов» добавлена расширением «УправлениеЛизингом»«Заимств. имя расширения» — фиолетовый
Сущность типовая, но расширение её дополнило:
- раздало дополнительные права (роль);
- добавило тип в состав определяемого типа или ПВХ;
- добавило объект в состав функциональной опции;
- добавило обработчик в подписку;
- привязало типовой объект к подсистеме расширения;
- добавило свойство в типовой XDTO-объект.
«Заимствование» помечается как на самой сущности (тег в карточке), так и на конкретной строке состава с указанием имени расширения. Это самый частый production-сценарий 1С-расширений: внедренец видит, какие именно элементы внутри типовой сущности добавлены расширением, без сравнения XML.
В модели данных это решено через origin-поля: для каждой коллекции (состав определяемого типа, элементы функциональной опции, права роли, объекты подсистемы) хранится карта «элемент → имя расширения». Аналитик видит карту целиком в одном клике.
«имя расширения» — переопределение обработчика
Применяется к сущностям, у которых есть функция-обработчик:
- регламентное задание (метод-обработчик подменён);
- конечная точка HTTP (метод-обработчик подменён);
- операция SOAP.
В карточке такой сущности виден исходный обработчик (что было до подмены) и имя расширения, которое подменило обработчик. Это важно при апгрейде: если типовой обработчик изменился, переопределение в расширении может не подцепить новую логику — и регламент / HTTP-эндпоинт будет работать «на старой версии» молча.
Также маркер виден в графе вызовов: на узле обработчика, который заменён, и на функции-перехватчике расширения (&Перед, &После, &Вместо).
Где маркеры встречаются
Маркеры расширений сквозные — они работают во всех разделах программы:
| Раздел | |||
|---|---|---|---|
| Дерево типов | — | ||
| Карточка объекта (вкладки) | — | ||
| Карточка роли | — | ||
| Параметры сеанса | — | ||
| Функциональные опции | — | ||
| Определяемые типы и ПВХ | — | ||
| Подписки на события | |||
| Регламентные задания | — | ||
| HTTP-сервисы и Web-сервисы | — | ||
| XDTO-пакеты | — | ||
| Граф вызовов | |||
| Конструктор профилей | — |
Все маркеры в интерфейсе строятся из полей графа знаний — один источник истины. Поля заполняются на этапе парсинга независимо от формата исходников (ZIP-выгрузка, EDT-проект, монорепо, отдельные репозитории, рабочая область EDT).
Зачем это при обновлении типовой
При обновлении типовой маркеры подсказывают, какие именно точки расширения зависят от изменений типовой:
- — если типовой обработчик изменился, переопределение в расширении может не подцепить новую логику. Регламентное задание или HTTP-эндпоинт нужно перепроверить.
- — если типовая роль или тип изменились, вклад расширения нужно пересмотреть. Расширение могло раздавать права на состав, который теперь другой.
- — если типовой объект, на который опирается сущность расширения, изменился, расширение нужно адаптировать. Это видно через граф вызовов: функции расширения, вызывающие изменённую типовую функцию.
Один взгляд на маркеры — и понятен полный список точек, которые нужно тестировать после апгрейда. Без сквозной подсветки каждое такое расследование занимает часы.
Чем отличается от стандартного Конфигуратора 1С
Сводная таблица «вопрос → как ответить». Включены кейсы, которые либо невозможны в Конфигураторе, либо требуют ручного обхода десятков окон. Анализатор — только анализ, без редактирования: правки кода и обновление ИБ остаются за Конфигуратором / EDT.
Структура и навигация
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все объекты одного типа в одном списке | Ветка дерева | Дерево со счётчиками |
| Поиск по синониму, а не по имени | Только Ctrl+Shift+N по имени | Поле поиска в шапке |
| Объекты типовой и расширений вместе | Разделено | Объединено, с маркерами и |
| Счётчики в реальном времени | — | Счётчики на каждом узле |
| Переключение между загруженными конфигурациями | Две сессии | Смена системы в выпадающем списке (сравнение — только версий и поставок одной системы, в режиме «Версии») |
Зависимости и связи
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Кто ссылается на этот объект | Поиск ссылок | Вкладка «Связи» |
| Кто читает объект в запросах 1С | Полнотекстовый поиск | Вкладка «Запросы» |
| Кто вызывает эту функцию | Поиск ссылок | Входящие вызовы в графе |
| Что вызывает эта функция | Вычитывание текста | Исходящие вызовы в графе |
| Транзитивная цепочка вызовов | — | Граф с раскрытием |
| Косвенный путь через подписку | Надо помнить о подписке | Автоматически |
| Модули-гиганты и точки нагрузки | — | Фильтр « Монстры» |
Роли и безопасность
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все RLS-выражения роли в одном месте | Каждое право вручную | Кликабельная пометка (RLS) и окно с текстом |
| Параметры сеанса в RLS | Поиск по тексту | Счётчик на параметре |
| Привилегированные установки | Вычитывание УстановитьПривилегированныйРежим |
Пометка PRIV в карточке параметра |
| Предпросмотр профиля прав | Создание тестового профиля | Конструктор профилей |
| Права роли по объектам | В окне роли | В карточке роли — дерево прав по объектам с пометкой (RLS) |
Программные проверки РольДоступна |
Поиск по коду | Видны рядом с правами роли |
Внешние API и расширения
| Кейс | Конфигуратор | Analyzer 1C |
|---|---|---|
| Все конечные точки REST в одной таблице | Дерево сервисов | Таблица «N сервисов, M конечных точек» |
| Сравнение XDTO-пакетов | Две сессии | Изменённые пакеты в срезе сверки версий (по сигнатуре: namespace + число типов/свойств + импорты) |
| Переопределение обработчика HTTP расширением | Сравнение XML | на конечной точке |
| Какие подписки расширение добавило | Открыть расширение отдельно | в карточке объекта-источника |
| Какие регламенты расширение переопределило | Сверка вручную | и исходный обработчик |
| Какие функции расширения опираются на типовую | Анализ кода | Граф вызовов с маркерами |
| Влияние расширения после обновления типовой | — | Все маркеры в одном месте |
Когда Analyzer 1C не заменяет Конфигуратор
Чтобы не создавать ложных ожиданий, Analyzer 1C — только анализ, без редактирования. Если нужно:
- править XML/BSL — Конфигуратор или EDT;
- запустить отладку — Конфигуратор;
- собрать
.cf-файл, выкатить обновление — Конфигуратор; - работать с реальной информационной базой — Конфигуратор.
Analyzer 1C показывает состояние конфигурации, не оперирует информационной базой и не выполняет код. Он отвечает на вопросы «что есть в коде» и «как это связано» — без рисков случайных изменений.
Типичная связка инструментов:
- В Analyzer 1C находите проблему (влияние изменения, конфликт прав, вклад расширения) и понимаете контекст.
- По указанному имени модуля / функции / объекта открываете его в Конфигураторе (EDT) и правите.
- Перезагружаете конфигурацию в Analyzer 1C — проверяете, что правка отражена в графе как ожидалось.
Дополнительные возможности Analyzer 1C
Карточка объекта и группа «Связи»
Карточка — центральный экран программы: с неё начинается большинство расследований («куда ссылается этот документ», «кто его читает», «какие роли дают на него права», «какие команды есть»). В шапке — иконка типа метаданных, синоним и маркер / если есть. Под шапкой — вкладки: Связи, Функции, Команды, Запросы, Роли.
Группа «Связи» — самая важная: таблица всех рёбер графа, ведущих в объект или из него. Группировка по типу, фильтр по направлению (входящие/исходящие), фильтр по типу метаданных. Каждое ребро несёт dir («Ссылается», «Подписан», «Обработчик», «Запускает», «В составе» и т.п.), что делает таблицу читаемой без перехода на каждое ребро в графе.
Документ «Реализация товаров и услуг» — 477 связей: 104 общих модуля, 69 справочников, 57 документов, 32 регистра накопленияЕсли ребро добавило расширение — оно подсвечено: например, « Источник ERP_IFRS» для подписки расширения на типовой документ. Сразу видно вклад расширения, не обходя список расширений отдельно.
Подписки на события и регламентные задания
Подписки на события (EventSubscription) — один из самых «невидимых» источников поведения 1С. При записи документа, константы или набора записей регистра срабатывают процедуры из общих модулей, перечисленные в поле Handler. Найти эти цепочки вручную сложно: нужно открыть каждую подписку и понять, какие объекты она затрагивает.
Анализатор парсит раздел EventSubscriptions основной конфигурации и расширений, извлекает событие (ПередЗаписью, ПриЗаписи, ОбработкаПроведения), список источников и обработчик, и строит двунаправленные связи в графе: от объектов-источников к подписке и от подписки к общему модулю-обработчику.
Подписка «Зарегистрировать данные первичных документов» (При записи) затрагивает 212 документов — от объектов-источников к подписке и к общему модулю-обработчикуРегламентные задания — ещё одна точка входа в логику конфигурации. В карточке регламента видны: расписание, обработчик в формате <ОбщийМодуль>.<Метод>, контекст исполнения (сервер/клиент/внешнее соединение), маркер если обработчик переопределён расширением.
Кейс. При диагностике медленной записи документа достаточно открыть его карточку и посмотреть блок «Подписки» — все подписки, срабатывающие при записи, видны как отдельные строки. Если на одном документе висит пять подписок «Перед записью», каждое сохранение последовательно вызывает пять процедур — вот и источник «тормозов».
Конструктор профилей
Профиль в БСП — это пользовательская совокупность ролей. Аналитику важно увидеть суммарные права до фактического создания профиля: какие объекты будут доступны, какие действия можно будет выполнять, нет ли неожиданных пересечений прав между выбранными ролями. В Конфигураторе профиля как сущности нет — есть роли, и проверить «что получится» можно только при тестировании в ИБ.
Конструктор профилей даёт предпросмотр прав до создания: отмечаете флажками нужные роли в левой панели, в правой сразу появляется агрегированная матрица «объект × право», список конфигурационных прав и список подсистем.
Профиль из трёх ролей (678 разрешений) — итоговые разрешения, агрегированные по объектам конфигурацииВ матрице — маркеры расширений на объектах: — объект из расширения, — типовой объект с вкладом расширения в права. Пометка (RLS) на правах с ограничением, текст условия — в том же окне, что в карточке роли. Если в матрице обнаружили объект, на который суммарно даётся Удаление, — это повод обсудить такое право с заказчиком профиля до того, как профиль создан.
Функциональные опции
В типовых на 1С — десятки и сотни функциональных опций («Использовать партионный учёт», «Учёт по складам», «Многофирменность»), которыми внедренец и архитектор управляют видимостью и поведением конфигурации. Раздел «Функц.опции» в левой панели даёт три ответа сразу: что опция отключает в интерфейсе, где её значение читается в коде, и какие опции затрагивают конкретный объект, когда вы открываете его карточку.
Сайдбар «Функц.опции» в режиме ЕРПУХ — больше тысячи опций, активные сверху, устаревшие полупрозрачные внизуВ каждой строке списка — заголовок опции и три счётчика: Состав (элементов в Content), Контролирует (объектов, реально отключаемых), Проверяется (функций BSL, где значение опции читается через ПолучитьФункциональнуюОпцию).
Если опция собственная для расширения — на ней маркер с именем расширения. Если у опции стоит «Привилегированное получение значения» — маркер. Флажок « Только затронутые расширениями» оставляет в списке только опции, чей состав или само определение правит какое-нибудь расширение. Это даёт точный ответ «что сломается при выключении опции X» до фактического выключения в ИБ.
Внешние API
Раздел «Внешние API» показывает все точки входа в конфигурацию в одном месте: HTTP-сервисы с URL-шаблонами и обработчиками методов (GET/POST/PUT/DELETE), Web-сервисы (SOAP) с операциями и привязкой к BSL-функциям, регламентные задания с расписанием и handler-методом, подписки на события и планы обмена. Для каждой записи виден контекст исполнения (сервер/клиент/внешнее соединение) и быстрая ссылка на сам обработчик в коде. Особенно полезно при аудите безопасности и интеграций: за одну страницу видно весь периметр взаимодействия системы с внешним миром.
Программный доступ к графу (MCP)
В платной версии граф конфигурации доступен не только через интерфейс, но и программно — по протоколу MCP (Model Context Protocol). Это открывает ИИ-ассистенту разработки и вашей автоматизации прямой доступ к «анатомии» системы: составу объектов, связям, анализу влияния, ролям и циклам — теми же данными, что видны в интерфейсе.
Назначение — заземление ИИ-помощника на реальное устройство конфигурации: его выводы опираются на граф, а не на догадки модели. Описание протокола и перечень доступных операций поставляются отдельным документом.
Изучение подсистем
Режим знакомства с незнакомой конфигурацией через её собственный язык: подсистемы. Слева — список всех подсистем, отсортированный по числу документов (служебные платформенные скрыты по умолчанию). Клик по любой открывает карточку процесса с двумя видами:
- Список — инициирующие документы → промежуточные → завершающие, со ссылками друг на друга через регистры и проводки;
- Граф — тот же путь визуально, с подсветкой цепочки от выбранного документа.
Это даёт прямой ответ на вопрос «как здесь устроена работа», не заставляя вручную обходить дерево объектов: за минуты видно, с чего процесс начинается, чем заканчивается, и какие документы участвуют посередине. Любую подсистему можно пометить как служебную через -меню — пометка сохраняется между сессиями.
Визуализация графа и статистика конфигурации
Переключатель «Таблица / Граф» в правой панели визуализирует зависимости выбранного объекта в виде интерактивного графа. Узлы — связанные объекты, рёбра — типы связей (вызовы, ссылки, заимствования). Правый клик по узлу — переход к зависимостям этого объекта (навигация вглубь графа).
Граф зависимостей документа «Реализация товаров и услуг»Вкладка «Инфо» показывает общую статистику загруженной конфигурации: число подсистем, модулей, функций, вызовов, ссылок реквизитов, запросов к таблицам и ролей. Удобно для быстрой оценки масштаба: 1С:ERP. Управление холдингом — 907 подсистем, 28 342 модуля, 699 793 функции, 60 470 вызовов.
Статистика 1С:ERP. Управление холдингомЗагрузка из ZIP, git и бинарных .cf (6 форматов)
Поддерживаются 6 способов загрузки конфигурации, формат определяется автоматически:
- ZIP — выгрузка 1С через «Конфигурация → Выгрузить конфигурацию в файлы» (с расширениями внутри архива).
- Монорепо —
src/cf/+src/cfe/{ext1, ext2, …}в одной git-папке. - Отдельные git-репозитории — main и каждое расширение в своём репозитории, клонируются в подпапки одной папки.
- EDT-проект — одиночный git-клон с
Configuration.xml/.mdoв корне. - EDT workspace — несколько EDT-проектов на произвольной глубине в одном git-репо (например, основная конфигурация и расширения в одном клоне).
- Бинарные
.cf/.cfe— прямой бинарный контейнер поставки 1С без предварительной выгрузки в файлы, включая конфигурации-гиганты (обрабатываются потоково).
В диалоге загрузки укажите имя папки и выберите ZIP или URL git-репозитория с веткой. Для приватных репозиториев — токен в диалоге или переменной окружения ANALYZER_GIT_TOKEN в .env. Расширения подхватываются автоматически по маркеру ConfigurationExtensionPurpose.
Диалог «Загрузить конфигурацию»: вверху — выбор источника (ZIP-файл, бинарные .cf/.cfe, git-репозиторий); на примере — клонирование из git с указанием папки, URL и веткиПри повторном клонировании того же URL делается git pull в существующей папке — без дубликатов. Разбор и загрузка ERP УХ (28 342 модуля) занимает около 15 минут. Можно загрузить несколько конфигураций и переключаться между ними через выпадающий список в шапке.
Варианты организации репозитория
Поддерживаются шесть способов загрузки конфигурации — инструмент автоматически определяет тип конфигурации и формат выгрузки. Ниже — три самых распространённых git-варианта; отдельно работают ZIP-выгрузка из Конфигуратора, EDT workspace (несколько EDT-проектов в одном git-репо) и прямая загрузка бинарных .cf/.cfe.
Монорепо
Основная конфигурация — в src/cf/, расширения — вsrc/cfe/{имя_расширения}/.- Один репозиторий — один клон, всё определяется автоматически.
Отдельные репозитории
- Основная конфигурация и каждое расширение в отдельном репозитории.
- Клонируются в подпапки одной папки (
main/,ext1/,ext2/).
EDT-проект или одиночный репозиторий
- Репозиторий содержит одну конфигурацию (основную или расширение).
- Формат (git-sync или 1C:EDT) определяется автоматически. EDT workspace с несколькими проектами в одном репо — тоже поддерживается.
Инструмент автоматически определяет, что является основной конфигурацией, а что расширением — по наличию ConfigurationExtensionPurpose в Configuration.xml или маркера mdclassExtension:ConfigurationExtension в .mdo для EDT. При повторной загрузке выполняется git pull: для монорепо — один раз, для отдельных репозиториев — в каждой подпапке, для EDT workspace — в каждом найденном git-корне.
Развёртывание
Analyzer 1C поставляется как готовый Docker-образ. Для развёртывания нужен только Docker — ни Python, ни Node.js, ни ArangoDB устанавливать отдельно не требуется. Всё упаковано в образ.
Windows 10/11:
- Скачайте Docker Desktop
- Запустите установщик, перезагрузите компьютер
- Убедитесь, что Docker запущен (иконка в трее)
Ubuntu / Debian:
sudo apt update sudo apt install -y docker.io docker-compose-plugin sudo systemctl enable --now docker sudo usermod -aG docker $USER # Перелогиньтесь, чтобы применить группу
Скопируйте на сервер файлы из архива поставки:
analyzer-1c-offline.tar— Docker-образdocker-compose.prod.yaml— конфигурация запускаdeploy.sh(Linux) илиdeploy.bat(Windows) — скрипт деплояstart.sh,stop.sh(Linux) или.bat-варианты (Windows) — повторный запуск и остановка.env.example— пример настройки переменных окружения
Поставка автономна: в одном архиве и приложение, и ArangoDB — они поднимаются вместе одной командой, отдельно базу устанавливать не нужно.
Linux:
bash deploy.sh
Windows (cmd или PowerShell):
deploy.bat
Скрипт загрузит образ, запустит контейнер и удалит архив. После запуска приложение доступно по адресу http: / localhost:8000.
Для остановки: bash stop.sh / stop.bat. Повторный запуск: bash start.sh / start.bat.
Откройте веб-интерфейс, в выпадающем списке систем выберите «Загрузить новую...» и укажите папку для загрузки и ZIP-выгрузку конфигурации либо адрес git-репозитория и ветку. Расширения должны загружаться в ту же папку, что и основная конфигурация, с другим именем архива. Разбор и загрузка ERP УХ (28 342 модуля) занимает около 15 минут. Можно загрузить несколько конфигураций и переключаться между ними.
Обновление ставится поверх текущей установки тем же способом, что и первая установка: скопируйте в ту же папку новый analyzer-1c-offline.tar из свежей поставки и запустите deploy.sh / deploy.bat ещё раз. Скрипт загрузит новый образ и пересоздаст контейнер приложения.
Данные при обновлении не теряются. Обновляется только образ приложения. База ArangoDB (она хранится в отдельном томе Docker) и папка conf/ с загруженными конфигурациями остаются на месте, поэтому после обновления сохраняются:
- все загруженные конфигурации и расширения;
- зафиксированные версии и поставки, история сверки и объединения;
- уже построенный граф знаний — он сразу доступен после обновления.
Перезагружать конфигурацию заново не требуется, если обновление не меняет логику загрузки. Но если в новой версии доработан разбор (новые поля, коллекции графа, парсеры объектов или связей), конфигурацию нужно перезагрузить кнопкой «Перезагрузить» в шапке — чтобы граф пересобрался с учётом улучшений. Что именно меняется в каждой версии, указано в её описании.
История версий
Перезагрузка систем: ТРЕБУЕТСЯ — иначе область объявления методов, реквизиты и формы, добавленные расширениями, состав движений, синонимы полей и состав общих форм останутся в прежнем разборе, а сверка модулей покажет изменения там, где ничего не менялось.
Новое
Матрица прав ролей выгружается файлом
Права ролей были видны только на экране, по одной роли за раз: чтобы сверить роли между собой или отдать выборку на аудит, матрицу приходилось переписывать руками. Теперь из карточки роли выгружается вся матрица прав системы — файлом, который Excel открывает двойным щелчком, с русской кодировкой и разделителем, к которым он привык. Выгружается именно вся матрица, а не одна открытая роль: роли сверяют между собой, а не поодиночке; при открытой подсистеме отбор по ней сохраняется.
Граф вызовов: диаграмма выгружается текстом, который можно вставить в задачу
Граф вызовов можно было забрать только картинкой. Теперь рядом появилась выгрузка диаграммой Mermaid — это текст, который рисуется прямо в описании задачи, в базе знаний и в документации: через год такую диаграмму можно прочитать и поправить, в отличие от снимка экрана. Выгружается то, что сейчас на экране, — скрытое фильтром в файл не попадает, иначе текст расходился бы с картинкой.
Граф вызовов: типовые функции убираются с полотна
В анализе функций и в отчёте о циклах фильтр «скрыть типовые» был давно, а в графе вызовов — нет: цепочка вызовов тонула в вендорских общих модулях, которые заведомо никто править не станет. Теперь флажок есть и там, и он называет цену нажатия — сколько узлов исчезнет. Функция, с которой начали, остаётся на полотне всегда, даже если она сама типовая. По умолчанию фильтр выключен: граф вызовов читают, чтобы увидеть путь целиком.
Предупреждение, когда эталон поставщика снят с другой версии
Пометка «доработана» означает «тело отличается от эталона», а не «это ваша доработка»: если эталон снят с другой версии поставки, отличием окажется и правка вендора между редакциями. Теперь везде, где работает фильтр типовых — в анализе функций, в отчёте о циклах и в графе вызовов, — стоит предупреждение о расхождении версий, чтобы чужой код не был принят за свой.
Настройки объединения выгружаются и в формате 1C:EDT
Analyzer готовил файл настроек объединения только для Конфигуратора, и для тех, кто обновляет конфигурацию поставщика через 1C:EDT, рекомендация была бесполезна: EDT принимает собственный формат. Теперь формат выбирается при выгрузке. Вид метаданных, для которого соответствия в EDT нет, не проглатывается молча — о нём сказано отдельно, потому что файл, потерявший часть решений, выглядит полным и его применят, считая, что учтено всё.
Обращения к базе внутри цикла видны в таблице функций
Analyzer считал обращения к базе внутри цикла, но показать их было негде — числа доставались только через программный интерфейс. Теперь в таблице функций есть своя колонка, а подсказка раскладывает число по видам: запрос в цикле, поход за объектом и разыменование ссылки лечатся по-разному. Заодно к этим видам добавился самый частый в 1С: обращение вида «Выборка.Номенклатура.Артикул» внутри цикла, где каждая итерация идёт в базу за реквизитом. Пустая клетка не означает «в цикле чисто»: у систем, загруженных прежней версией, такого расчёта нет вовсе. Появится после перезагрузки систем.
В карточке функции видно, что процедура меняет переданные ей данные
В 1С коллекции и объекты передаются в параметры по ссылке, поэтому процедура часто «возвращает» результат, меняя переданное: возврата у неё нет, а данные у вызывающего появляются. Прежде такой параметр выглядел просто входным, и анализ потока данных терял вклад процедуры целиком. Теперь рядом с именем параметра сказано, что с ним происходит: заполняется, дополняется, очищается, принимает временные таблицы. Локальные переменные с этим не путаются — сверка идёт со списком параметров. Появится после перезагрузки систем.
Поиск по списку пользователей
Список учётных записей показывался целиком, без поиска: пока учёток десяток, это удобно, а после синхронизации с каталогом в списке оказывается весь состав групп, и нужного человека можно найти только прокруткой. Теперь над таблицей есть строка поиска — по логину, роли, источнику учётной записи и по группам каталога; несколько слов через пробел требуют все сразу. Рядом счётчик «показано N из M», чтобы отфильтрованный список не читался как «часть пользователей пропала».
Ассистент получает справку о конфигурации одним вызовом
Чтобы узнать, какие расширения стоят в системе и каким префиксом они метят свои объекты, ассистенту нужно было знать ответ заранее: список расширений в графе был, а достать его по одному имени системы было нечем. Теперь есть отдельный запрос: название и версия конфигурации, состав расширений с числом заимствованных объектов и перехваченных методов, префиксы собственных объектов расширения и состав конфигурации по видам метаданных. Именно префикс отвечает на вопрос «это слой доработки или типовой код» прямо в коде.
Тело метода зафиксированной версии читается по человеческому адресу
Тела методов в зафиксированных версиях поставки хранились и раньше, но адресовались внутренним ключом, поэтому прочитать тело вендорского метода при разборе обновления можно было только обходным путём. Теперь метод запрашивается по понятному адресу — версия, объект, имя метода, — и тем же способом получается сравнение «было / стало» между двумя версиями. Если имя носят несколько методов (тёзки в 1С обычное дело), в ответ идёт перечень кандидатов, а не первый попавшийся.
Улучшения
Тела методов в окне сравнения версий открываются быстрее, а несколько человек не делают одну работу дважды
Чтобы показать тело метода зафиксированной версии, Analyzer каждый раз разбирал её состав целиком — у крупной конфигурации это сотни мегабайт на один показ. Открыть второй метод стоило столько же, сколько первый, а два человека, смотревшие одну и ту же поставку, повторяли эту работу каждый за себя. Теперь разобранный состав версии сохраняется рядом с уже существующим кешем разбора модулей и переиспользуется — и следующими показами, и другими пользователями, и после перезапуска. Место ограничено тем же общим лимитом кеша, отдельной настройки размера не требуется; при необходимости кеш отключается параметром ANALYZER_FXMAPS_CACHE=0. Работает сразу, перезагрузка систем не нужна.
Размещение на сервере настраивается, а не правится в файлах поставки
Каталог с загруженными конфигурациями, внешний порт и обращение к Docker через sudo прежде были зашиты в файлы установки: чтобы поставить Analyzer рядом с другой системой, приходилось править их вручную — и правка терялась при обновлении. Теперь всё три задаются в файле настроек .env: ANALYZER_CONF_DIR (свой каталог конфигураций), ANALYZER_PORT (если 8000 занят) и ANALYZER_DOCKER_SUDO (по умолчанию Analyzer сам проверяет, нужен ли sudo, и не спрашивает пароль у тех, кто работает с Docker напрямую). Умолчания прежние — у существующих установок ничего не меняется.
Сопоставление с эталоном поставщика на крупных базах идёт в разы быстрее
На большой конфигурации (около семисот тысяч функций) фаза сопоставления с эталоном занимала у клиента больше десяти минут, тогда как на быстром оборудовании — двенадцать секунд: пересчёт переписывал пометку у каждой функции, хотя тот же эталон почти для всех даёт прежний ответ. Теперь переписывается только то, что действительно изменилось, а пропущенное названо в журнале — иначе строка «Записано: 0» читалась бы как «пересчёт ничего не сделал».
Состав объекта называет реквизиты не только именем, но и представлением
Имя реквизита в 1С сплошь и рядом не совпадает с его смыслом — смысл несёт синоним, то, что видит пользователь. Ассистент получал только символьное имя и выбирал поле вслепую: «СрокЛизинга» на поверку оказывался количеством платежей. Теперь состав объекта, а также измерения и ресурсы регистров отдают синоним поля. Синоним, дословно повторяющий имя, не отдаётся — у 1С это автоподстановка. Появится после перезагрузки систем.
Состав объекта говорит, какие реквизиты добавило расширение, а какие пришли из конфигурации
Пометка о расширении стоит только у реквизита, который расширение добавило, — у реквизита базовой конфигурации её нет вовсе. Отсутствие пометки утверждением не является, но читалось именно так: у документа с 75 реквизитами шапки шесть без пометки принимались за весь состав вендора, а остальные 69 — за несуществующие. Теперь состав прямо называет обе стороны и объясняет, что означает отсутствие пометки.
Слой и контекст метода названы прямо, а не выводятся по догадке
Модуль объекта в графе один: методы расширения лежат в нём вместе с типовыми. Ассистенту приходилось судить о слое по префиксу имени — а метод расширения бывает написан и без префикса, и тогда правка адресовалась в типовой модуль, откуда она исчезнет при обновлении конфигурации. Теперь и слой (типовой код или расширение), и контекст компиляции метода (клиент, сервер) отдаются отдельными полями, которые можно сверить, а не строкой, которую надо разглядеть в теле.
Поиск объекта разбирает слитный запрос по словам
«ГрафикОплат» не является подстрокой «ГрафикиОплатЛизинга» — между словами стоит «и», — поэтому рабочий регистр не показывался вовсе, а ответ выглядел исчерпывающим. Теперь, если по точному совпадению нашлось мало, поиск дополнительно добирает кандидатов по отдельным словам запроса и говорит об этом отдельно. Заодно подсказано смотреть на синонимы: пометка «(не используется)» в синониме означает, что объект устаревший.
Ответы ассистенту стали компактнее там, где он платил за дубль
Состав объекта и паспорт объекта отдавали плоский список всех реквизитов — полную копию того, что лежит рядом разложенным по шапке и табличным частям. На крупном документе это до половины ответа, и она переносится из шага в шаг вместе с историей диалога. Теперь дубль можно не запрашивать. Прежние вызовы работают как раньше — ответ у тех, кто ничего не менял, не изменился.
Поиск в интерфейсе подписывает модуль так же, как дерево слева
В подсказке поиска стояло символьное имя модуля, тогда как в дереве типов тот же объект подписан синонимом, — сопоставлять приходилось вручную. Теперь синоним стоит основным текстом, а символьное имя мелким в скобках, как в остальных таблицах.
Служебный кеш перестал разрастаться вопреки заданному бюджету
Кеш разобранных модулей состоит из сотен тысяч мелких файлов, и место считалось по размеру содержимого, а не по реально занятому на диске — на замере это 1,1 МБ против 119 МБ, разница в сто раз. Из-за этого уборка не запускалась, когда была нужна, а отчёт всё это время сообщал, что кеш в пределах бюджета. Теперь считается занятое место, и рядом отдельно показан объём содержимого — чтобы разрыв был виден.
Исправления ошибок
Реквизиты, добавленные расширением к типовому документу, доезжают до графа
У документа, к которому расширение дописало сотни реквизитов, Analyzer показывал шесть — всё, что добавило расширение, терялось при загрузке. Ассистент на такой картине объявлял отсутствующим реквизит, стоящий в составе семьдесят первым, и строил обходное решение через чужой объект. Причина была в запросе, который отрабатывал без ошибки, ничего не записав, а счётчик в журнале считал попытки, а не факт записи, — поэтому загрузка отчитывалась об успехе. Теперь считается записанное, а промах называет себя отдельной строкой. Появится после перезагрузки систем.
Форма, созданная расширением, больше не выдаёт себя за типовую
Принадлежность формы бралась от объекта-владельца, поэтому форма, которой в основной конфигурации не существует вовсе, уезжала в граф как типовая и заимствованная. На языке 1С эта пара означает ровно одно: правку класть перехватом «после» или «вместо», — а для собственной формы расширения перехват не свяжется. Теперь такая форма названа своей формой расширения, и заимствование с неё снято. Появится после перезагрузки систем.
Поиск больше не отрицает существование расширения
Запрос по имени расширения отвечал «ничего не найдено» — при том что граф расширение знает: и его состав, и заимствования, и перехваты. Хуже пробела в поиске было то, что такой ответ читается как разрешение заключить «в конфигурации этого нет». Теперь расширение находится и по имени, и по названию, а в ответе прямо сказано, что объекты с таким именем не найдены, но расширение существует.
Ответ «функции нет» больше не выдаётся из-за регистра букв
Встроенный язык 1С регистронезависим, а граф сравнивал имена буквально: тот же метод, набранный строчными, получал утвердительный ответ «функция не найдена». Ответ читается как факт о системе — и ассистент записывал в отчёт, что тела обработчиков получить не удалось. Теперь при промахе имя разрешается по системе и в ответ идёт точное написание из графа. Быстрый путь поиска не тронут: на живой базе в графе миллионы функций, и «починка» через приведение имён превратила бы каждый вызов в перебор.
Синхронизация с каталогом видит сотрудников из вложенных групп
В группу, сопоставленную роли Analyzer, обычно вкладывают группы подразделений — это штатная раскладка Active Directory. Синхронизация видела только прямых членов: вложенную группу она молча пропускала, и её сотрудники не заводились вовсе, а отчёт показывал «заведено 0» при непустой группе. Теперь вложенность разворачивается вглубь, с защитой от закольцованных групп. Вход разбирает её так же — иначе синхронизация человека заводила бы, а вход отказывал ему «нет сопоставленной группы». Сбой на одной ветке обхода не роняет синхронизацию, но называет себя в журнале.
Перезагрузка расширений даёт ту же картину, что полная загрузка
Кнопка «Перезагрузить расширения» — быстрый путь: она обновляет слой доработок, не перечитывая конфигурацию целиком. Числа после неё обязаны совпадать с полной загрузкой, а расходились сразу в нескольких местах: пометка «тронут расширением» не переставлялась ни у одного вида объектов, кроме общих модулей (на рабочей базе — 471 помеченная вершина против 32 обновлённых); пятая часть перехватов не попадала в граф, потому что рёбра строились раньше своих целей; формы заимствованных объектов приезжали с отметкой «модуля нет» при живом модуле на четыреста методов; а половина расчётов по функциям расширений — риски проведения, доступ к движениям, метрики циклов — не считалась вовсе, потому что документ функции собирался в расширениях отдельным кодом. Всё перечисленное сведено к общему пути.
Состав движений заимствованного документа включает регистры расширения
Расширение доносило на заимствованный документ команды, реквизиты и свойства шапки, а состав движений — нет: регистры, добавленные расширением, до графа не доезжали. Из-за этого отчёт о рискованных движениях выдавал красный риск на собственный регистр документа, а карта влияния недосчитывала как раз ту часть системы, которую дописал внедренец. Появится после перезагрузки систем.
Отчёт о рискованных движениях перестал состоять из ложных срабатываний
На рабочей базе из 151 находки отчёта «заявлен регистр, а код туда не пишет» настоящих рисков было ноль: почти все лежали в общих модулях, куда набор движений приходит извне — параметром или из переданной структуры. У общего модуля своего документа нет вовсе, поэтому любые движения в нём чужие, как бы их ни получили. Теперь такие места не выдаются за дефекты, а показываются отдельным списком «проверить глазами». Модуль менеджера документа под правило не подпадает: там тот же код означает движения этого самого документа, и риск настоящий.
Состав и отпечатки общих форм читаются во всех форматах загрузки
Общая форма лежит в конфигурации не так, как форма объекта, и признак, по которому Analyzer её узнавал, на неё не срабатывал: состава у общих форм не было вовсе, а значит и сверка версий по ним молча не работала. По восьми загруженным системам это 2380 форм, а у одной из них без состава были вообще все общие формы. Теперь разбираются во всех шести форматах загрузки. Появится после перезагрузки систем.
После клонирования репозитория разбор начинается сам
Окно загрузки предлагало «Закрыть» ровно тогда, когда работа только начиналась: решение о запуске разбора принималось по последнему куску журнала, а отметка «клонирование завершено» приходит раньше — за ней идут ещё минуты работы с историей веток. Теперь решение принимается по всему журналу целиком.
Подключение ассистентов вернулось у строгих клиентов
При подключении к Analyzer по протоколу MCP сервер не сообщал свою версию, хотя протокол этого требует. Клиенты, которые ответ проверяют, отказывались от подключения целиком — со стороны Analyzer при этом всё выглядело исправным, в журнале ничего. Теперь версия передаётся.
Предупреждение о тяжёлом запросе перестало срабатывать всегда
Дельта к релизу, зафиксированному в Analyzer, оценивалась по линейке, откалиброванной для коммитов git, где объекты — это изменённые файлы. У релиза-снимка объекты — весь состав конфигурации, поэтому предупреждение выдавалось на каждый запрос и обещало сорок восемь минут там, где работа занимает секунды. Предупреждение, которое срабатывает всегда и ошибается в сто раз, перестают читать — вместе с тем, которое сработает по делу. Теперь у снимка своя линейка.
Поиск функции-обёртки над регистром работает индексом, а не перебором, и находит цепочки вызовов
Кнопка «найти обёртку» в карточке функции подбирала кандидатов полным перебором функций системы: на конфигурации ЕРП это 4,5 секунды ожидания на каждый показ. Причина оказалась не в объёме данных, а в самом запросе — он завершался ошибкой и молча уступал место запасному, медленному пути. Запасной путь к тому же не умеет главного: подниматься по цепочке «служебная процедура → вызывающая её экспортная», а именно так устроена типовая конфигурация — обёртка редко читает данные сама. Теперь поиск идёт по индексу (0,04–2 секунды в зависимости от того, насколько частое слово в подсказке) и показывает в том числе такие цепочки. Работает сразу, перезагрузка систем не нужна.
Права ролей на объекты расширений показываются так же, как в Конфигураторе
Роль, у которой стоит признак «Устанавливать права для новых объектов», не перечисляет объекты явно: права подразумеваются, а в выгрузке хранятся только снятые. Analyzer разворачивал такие права у ролей основной конфигурации, а у ролей, объявленных в расширениях, — нет: они попадали в граф с нулём прав. Из-за этого у документа, созданного в расширении, в карточке была видна одна роль «Полные права», хотя в Конфигураторе их десяток. Теперь границы прав совпадают с платформенными: в расширении признак действует на СОБСТВЕННЫЕ объекты этого расширения (роль одного расширения не получает прав на объекты другого), а роль основной конфигурации не покрывает объекты, добавленные расширениями, — для этого её заимствуют в расширение и права прописывают явно. Как следствие, у объектов расширения теперь показаны ровно те роли, что видны в Конфигураторе, а роль «Полные права» с них снята, если она не заимствована в расширение. Заодно перестали теряться права расширения на общие команды, выданные типовым ролям. Появится после перезагрузки систем.
Панель ревью не выдаёт недоступное хранилище за «замечаний нет»
Если замечания прочитать не удалось (база восстанавливалась, истёк таймаут), панель показывала «замечаний: 0» и не показывала блокеров — то есть ровно ту картину, по которой правку и вливают. Теперь в этом случае вместо счётчика показывается предупреждение: замечания прочитать не удалось, и это не значит, что их нет. В выгрузке такая защита была и раньше — теперь она и на экране.
Сводка коммитов у релиза-снимка честно говорит, что показана не вся история
Если с даты фиксации релиза в репозитории накопилось больше пятисот коммитов, сводка показывала участников и задачи по срезанному списку — и печатала его как полную картину. Руководитель сверял с трекером неполный перечень задач, не зная об этом. Теперь рядом с числом коммитов указано, сколько их всего и показаны ли все; при сравнении по git это работало и раньше, теперь так же и для релиза-снимка.
Методы формы теперь можно перечислить, а не только сосчитать
Состав формы показывал, сколько в ней процедур и функций, но не давал ни одного имени — а поиск по конфигурации локальные методы формы не показывает, потому что выносит наверх методы общих модулей. Из-за этого готовый механизм, лежащий в модуле формы, найти было нечем, и ассистент писал свой вместо существующего. Теперь состав формы отдаёт и имена методов, с отбором по части имени (регистр и «ё»/«е» не важны) — на формах с сотнями методов без отбора список бесполезен. Работает сразу, перезагрузка не нужна.
Видно, что общий модуль заимствован расширением
У всех видов объектов в дереве стоит пометка «тронут расширением», и только у общих модулей она не появлялась ни разу — при том что расширения заимствуют их десятками. Из-за этого на вопрос «этот общий модуль уже дорабатывали или его придётся заимствовать» ответить по дереву было нельзя. Теперь пометка ставится и на них. Появится после перезагрузки систем.
Подписки на события, оформленные «на все объекты вида», больше не теряются
Подписка, у которой источником указан тип целиком (все документы, все справочники, все наборы записей) или определяемый тип, прежде не попадала в Analyzer вовсе: на типовой конфигурации так терялась почти треть подписок. Из-за этого на вопрос «что срабатывает при записи этого документа» можно было получить пустой ответ, хотя подписки есть и работают. Теперь такие подписки видны, а у объекта показываются наравне с адресными — с пометкой, что подписка распространяется на весь вид объектов. Появятся после перезагрузки систем.
Стандартные реквизиты больше не удваиваются в составе объекта
Реквизиты, которые задаёт сама платформа (Дата, Номер, Код, Наименование, Родитель, Владелец, Период), показывались дважды: правильно — отдельным списком с русскими представлениями, и повторно — среди реквизитов конфигурации, с пустым типом. Из-за этого состав объекта не сходился с исходником, а ассистент считал платформенный реквизит доработкой конфигурации. Теперь они только в своём списке. Сверка версий по их свойствам работает как прежде.
Состав регистра: у измерений появился тип, у регистров накопления — вид
Прежде в составе регистра тип показывался только у измерений, ссылающихся на справочник или документ; у измерений с датой, числом или строкой поле оставалось пустым — таких в типовой конфигурации больше трети. Ассистент, строивший запрос к виртуальной таблице, видел имя измерения без типа. Кроме того, в составе не было указано, остаточный регистр накопления или оборотный, — а от этого зависит, какие виртуальные таблицы к нему применимы. Теперь и то, и другое отдаётся. Типы измерений появятся после перезагрузки систем; вид регистра виден сразу.
Отчёт без кода больше не выглядит несуществующим
Отчёты и обработки, целиком построенные на схеме компоновки данных, кода не содержат вовсе — и карточка объекта отвечала про них «объекта нет», то есть так же, как про действительно отсутствующий объект. При этом состав того же объекта другой командой показывался правильно, и два ответа противоречили друг другу. Хуже всего это было для ассистента: получив «объекта нет», он предлагал создать отчёт заново вместо существующего. Теперь карточка отвечает, что объект есть, а кода в нём нет ни строки, и подсказывает, где смотреть состав. Работает сразу, перезагрузка не нужна.
Проверка наличия регистра распознаётся во второй, более частой записи
Отчёт о рискованных движениях предупреждает, когда документ пишет движения в регистр, не проверив, что регистр ему доступен. Проверку в 1С пишут двумя способами, и Analyzer знал только один — через имя регистра строкой. Второй способ, через объект метаданных, распознан не был, поэтому корректно написанный типовой код попадал в отчёт как рискованный: на конфигурации ERP такими оказались десятки предупреждений подряд. Теперь распознаются обе записи. Появится после перезагрузки систем.
У регистров, добавленных расширением, виден состав ресурсов
Регистр, которого нет в типовой конфигурации и который целиком добавлен расширением, показывал измерения, но ни одного ресурса — состав выглядел так, будто записывать в регистр нечего. У регистров типовой конфигурации, доработанных расширением, всё было верно, поэтому расхождение легко было принять за особенность самого регистра. Теперь ресурсы собираются одинаково у тех и других. Появятся после перезагрузки систем.
Поиск не различает «ё» и «е»
В конфигурациях 1С эти буквы пишут вперемешку: в синониме объекта «отчётность», а в имени «отчетность». Поиск сравнивал написание буквально, поэтому запрос с «ё» мог не найти ничего там, где запрос с «е» находил сотню объектов. Теперь обе буквы считаются одной — и в строке поиска интерфейса, и в поиске объектов и методов у ассистента.
Обращение к незагруженной системе больше не выглядит как «ничего не найдено»
Если в запросе указано имя системы, которой в Analyzer нет (опечатка, не та база), поиск отвечал пустым списком — неотличимо от честного «искали и не нашли». Теперь такой запрос получает внятный отказ с перечнем загруженных систем.
Область метода и асинхронные методы: разбор обновлён у всех систем
Прежде часть модулей читалась из внутреннего кеша, снятого до исправления: служебный метод продолжал показываться в публичной области, а модуль с асинхронной процедурой мог выглядеть изменённым при сверке с поставкой, хотя в нём ничего не менялось. После перезагрузки систем такие модули разбираются заново.
Список правок с обезличенными авторами открывается вдвое быстрее
При отборе по автору с включённым обезличиванием история репозиториев прочитывалась дважды за один запрос: один раз — чтобы понять, кто такой «Автор 3», второй — чтобы пронумеровать псевдонимы. На системе с несколькими репозиториями это заметно задерживало открытие списка. Теперь история читается один раз. Заодно ушла скрытая опасность: номер автора и подписи в списке теперь заведомо берутся из одного перечня, а не из двух независимых.
Ревью не замедляется по мере накопления служебного кеша
Analyzer хранит рядом с конфигурациями кеш разобранных модулей, и после обычной загрузки в нём скапливаются сотни тысяч мелких файлов. Уборка этого кеша, которая запускается по ходу разбора, обходила папку трижды и опрашивала каждый файл дважды — на больших системах это добавляло задержки прямо во время ревью. Теперь папка обходится один раз, а каждый файл опрашивается однократно.
Перезагрузка систем: требуется — чтобы в графе появились обращения к модулям менеджера.
Улучшения
В поиске по графу вызовов видно, какому модулю принадлежит метод
Один и тот же объект может держать одноимённые методы в модуле объекта и в модуле менеджера — в подсказке поиска такие строки выглядели одинаково, и выбрать нужную можно было только наугад. Теперь рядом с именем объекта указан модуль: «Модуль объекта», «Модуль менеджера», «Форма «ФормаДокумента»».
Загрузка больше не ждёт уборки данных других конфигураций
В конце загрузки Analyzer убирал устаревшие данные не только той конфигурации, которую грузили, но и всех остальных, — и человек ждал окончания своей загрузки, пока система разбирает чужое. На крупной базе это добавляло минуты. Теперь такая уборка идёт фоном и загрузку не задерживает; в журнале названо, что именно отложено.
Журнал загрузки объясняет долгую очистку, а не молчит
Очистка старых данных сообщала о себе только по завершении, поэтому несколько минут тишины выглядели зависанием — тем более что время очистки не связано с числом записей напрямую: после большой уборки хранилище какое-то время работает медленнее. Теперь Analyzer называет, что именно очищает, и отчитывается о ходе, а сообщение о долгой операции указывает текущее занятие, а не предыдущее.
Исправление ошибок
Граф вызовов видит обращения к модулю менеджера
Вызов вида «Документы.ЗаказКлиента.Метод(…)» — штатный способ обратиться к публичному методу объекта — в графе не отражался вовсе: Analyzer сопоставлял с целью только обращения к общим модулям. Из-за этого экспортный метод модуля менеджера выглядел никем не вызываемым, хотя вызовы есть, и то же искажение уносили с собой анализ влияния, поиск неиспользуемого кода и цепочки проведения. Теперь такие обращения находят свою цель — в том числе у объектов расширения и у методов, добавленных расширением в модуль менеджера типового объекта. b88;A039; Изменение проявится после перезагрузки конфигурации.
Понятные слова в журнале загрузки
Из журнала убраны слова, которые ничего не говорят читателю: «отпущенные ретенцией» стало «с истёкшим сроком хранения», «осиротевший раздел прежнего sid» — «остался раздел от прежнего имени системы», «тела функций и форм (CAS)» — «уникальных текстов».
Перезагрузка систем: ТРЕБУЕТСЯ для ВСЕХ систем, независимо от способа загрузки. У конфигураций из файлов .cf и .cfe появился состав форм, которого прежде не было. У всех остальных изменился разбор модулей: описание метода теперь принадлежит методу, а не тексту вне процедур, и у методов появилась область объявления. До перезагрузки область в дереве правок останется пустой, а сверка со свежей поставкой покажет изменения там, где ничего не менялось. В меню «Перезагрузить» такие системы помечены отдельно.
Новое
Код-ревью по коммитам
Целый раздел, которого раньше не было: список правок команды с отбором по автору, задаче, ветке и периоду, дерево затронутых объектов по выбранному коммиту и окно кода «было / стало» рядом с ним. Дерево показывает не файлы, а объекты конфигурации: изменённые методы с их областями, текст вне процедур, состав форм, реквизиты, макеты и предопределённые данные — то, что в текстовом diff тонет в перегенерированном XML. Правки, для которых структурного разбора нет, открываются исходным файлом, а не замалчиваются. Работает на всех шести форматах загрузки, включая поставки .cf и .cfe.
Итог накопленного к релизу — как merge request
Отдельный вид того же раздела отвечает на вопрос техлида «что уедет в следующий релиз»: не список коммитов, а единая дельта. Сравнение трёхстороннее, от точки расхождения, — так же, как это делает git: хотфикс, залитый в релиз после ветвления, не показывается как ваша правка. Релиз задаётся пятью способами, потому что уклады разные: тегом по шаблону, веткой, коммитом, версией конфигурации (для укладов без тегов и веток) и зафиксированной в Analyzer версией — последнее работает даже там, где релиз уехал клиенту как .cf или .cfe и в репозитории его нет вовсе. Рядом — сводка: сколько коммитов, кто участвовал, какие задачи уедут в релиз.
Ревью с отметками, замечаниями и выгрузкой
По каждой строке дерева можно отметить «просмотрено» и записать замечание с уровнем — блокер, важное, замечание. Результат выгружается в Markdown для задачи трекера и в JSON для машин: выгрузка отвечает и на вопрос «что нашли и починили», потому что снятое замечание из неё не исчезает. Ревью нескольких людей по одному набору правок не смешиваются: очертание набора — часть его адреса.
Состав форм у конфигураций, загруженных из файлов .cf и .cfe
Форма такой конфигурации была в Analyzer пустой оболочкой: имя, заголовок, наличие модуля — и всё. Реквизиты, элементы, команды, параметры и обработчики событий формы не показывались и не искались, поэтому на вопрос «есть ли в этом механизме настройка по пользователям» ответ приходилось искать в Конфигураторе вручную, хотя ответ лежал в реквизитах формы. Теперь состав снимается так же полно, как у конфигураций из выгрузки в XML: замер на «1С:Зарплата и управление персоналом КОРП» дал 82 тысячи элементов и 33 тысячи реквизитов форм. Проверено сличением одной и той же конфигурации, загруженной обоими способами: состав совпал полностью.
Состав схем компоновки данных
Схемы СКД были слепой зоной: макет с настройками отчёта разбирался как непрозрачный файл, поэтому поля, наборы данных и связи в нём не искались и в графе не жили. Теперь состав схемы доезжает до графа и отдаётся агенту наравне с остальным составом объекта — вопрос «откуда отчёт берёт эту колонку» перестал требовать открытия Конфигуратора.
Ответ агенту «такой возможности нет» с основанием
Инструмент MCP, отвечая на вопрос о механизме, которого в конфигурации не существует, раньше просто ничего не находил — и это было неотличимо от неудачного поиска. Теперь отрицание приходит с основанием: где искали, что просмотрели и какими способами, — и агент может на него опереться вместо того, чтобы додумывать.
Улучшения
Показ правок стал быстрым на повторных открытиях
Разобранные модули, собранные состояния коммитов и отпечатки форм и макетов теперь запоминаются и переиспользуются, а модули, чей текст на сравниваемых сторонах одинаков, не разбираются вовсе. На крупной конфигурации дельта к релизу, занимавшая три четверти минуты, укладывается в секунды; повторное открытие той же правки приходит сразу. Запас памяти и места на диске под это ограничен и настраивается.
Окно кода выравнивает строки и даёт перемещаться по различиям
В процедуре на три сотни строк одна добавленная строка сдвигала всю оставшуюся часть колонки, и дальше строки стояли не напротив друг друга; различия приходилось искать прокруткой. Теперь стороны выровнены, различия перечислены, а переход к следующему и предыдущему — кнопками и клавишами, теми же, что в сверке версий.
Метод называет свою область
В дереве правок и в сверке версий у метода теперь видно, в какой области модуля он объявлен. Для ревью это содержательная разница: правка в «ПрограммныйИнтерфейс» меняет публичный договор модуля, правка в служебной области — нет.
Формы без модуля участвуют в сверке версий наравне с остальными
У формы без программного модуля не снимался отпечаток структуры, и сверка версий честно сообщала по ней «сравнить нельзя»: изменения такой формы между поставками оставались невидимыми. Теперь отпечаток снимается со всех форм одинаково — пустой модуль перестал быть причиной пропустить форму.
Уборка старых поколений конфигураций идёт сама
После нескольких перезагрузок одной системы её прежние разборы оставались в базе и занимали место, а убирались только при следующей загрузке. Теперь уборка идёт по расписанию и на старте приложения, независимо от того, загружают ли что-нибудь прямо сейчас.
Исправление ошибок
Папка служебного кеша считалась загруженной системой
Кеш разбора создаётся Analyzer сам, рядом с папками конфигураций. Он попадал в счёт систем: клиент, у которого лимит систем исчерпан не был, получал отказ «лимит исчерпан», а в Community после удаления единственной системы новую нельзя было загрузить вовсе. Массовая загрузка вдобавок заходила в эту папку и перечисляла её в журнале как систему.
Дельта к релизу могла сравнить не с тем
Выбор зафиксированной версии не проверял, что версия принадлежит этой системе: в сравнение попадал состав чужой конфигурации, и результат читался как «у нас всё переписано». Поставка-расширение сравнивалась с полной конфигурацией без сужения охвата, и сотни тысяч методов основной конфигурации объявлялись «появившимися после релиза».
Кнопка «Показать дельту» не спрашивала о тяжёлом разборе
Предупреждение «объектов много, разбор долгий» не показывалось никогда: согласие уходило само, и сервер начинал многоминутную работу без спроса. То же происходило при смене коммита после подтверждения — согласие переносилось на новый коммит.
Отказы при работе с замечаниями были не видны
Замечание, которое сервер не принял, выглядело записанным: поле ввода очищалось, а в списке его не было. Отметка «просмотрено» отжималась на глазах и молча возвращалась. Очистить название ревью было нельзя — поле само заполнялось прежним текстом. Теперь отказ показывается, а поле очищается только после успешной записи.
Выгрузка ревью могла назвать нечитаемое отсутствующим
Если замечания не удавалось прочитать, выгрузка писала «Замечаний нет» — и такой файл, отправленный в задачу, читался как разрешение вливать. Теперь это отдельное сообщение, а машинный формат несёт признак, по которому автоматика различит «нет замечаний» и «не прочитали».
Числа в сводке правок были неполными
«Коммитов: 500» означало не число коммитов, а потолок выдачи; участники и задачи считались по этому же срезанному списку, и техлид сверял с трекером неполный перечень. Число файлов вне объектов метаданных показывалось по длине показанного куска. Теперь называется полное число, а срез объявляется срезом.
Разбор модулей путал области и асинхронные методы
Область, закрытая строкой с комментарием («#КонецОбласти // ПрограммныйИнтерфейс» — частый стиль), не закрывалась: все методы ниже, включая служебные, помечались публичной областью. Метод, объявленный как асинхронный, попадал в правки дважды — и как метод, и как текст вне процедур.
В окно открывался не тот исходный файл
Строка расширения могла открыть файл другого расширения, дополняющего тот же объект. Строка «Предопределённый» открывала описатель объекта, где предопределённых данных нет, и показывала «различий 0» на месте настоящей правки. Состав формы переименованного объекта не показывался вовсе: сторона «до» искалась по новому имени.
Способ «версия конфигурации» не работал на проектах 1C:EDT
Единственный способ задать релиз там, где нет ни тегов, ни веток, на проектах EDT не находил ничего и объяснял это тем, что историю обрезали при клонировании. Причина была в разборе описателя конфигурации, а не в репозитории клиента.
Закрыты замечания по безопасности
Ссылка на релиз, приходящая из запроса, доходила до git без проверки и позволяла записать файл правами приложения. Замечания и сессии ревью правились и удалялись по одному ключу, без проверки того, что они принадлежат доступной пользователю системе. Действия с ревью не попадали в журнал аудита, поэтому удаление чужой сессии со всеми замечаниями следа не оставляло.
Видно, какие конфигурации собраны прежней версией
Analyzer понимал, что данные конфигурации собраны старой версией, но сообщал об этом только там, где это мешало: в дереве типов, в отчёте о рисках, в сравнении версий. Узнать это заранее, выбирая конфигурацию для перезагрузки, было нельзя — список выглядел одинаково. Теперь в меню «Перезагрузить» такие конфигурации помечены, а в подсказке названо, чего именно не хватает: устаревшего состава графа, несобранных данных для отдельных проверок или разбора, при котором сравнение со свежей поставкой покажет ложные изменения.
Отчёты о рисках говорят, когда проверка не проводилась
Часть отчётов опирается на данные, которые снимаются в момент загрузки конфигурации. Если система была загружена версией Analyzer, в которой нужного разбора ещё не было, отчёт возвращал пустой список — и это читалось как «рисков нет», хотя проверка не выполнялась вовсе. Теперь такой отчёт прямо сообщает, что данных для проверки нет, и предлагает перезагрузить конфигурацию; в панели «Риски обновления» подобный класс помечается «не проверялось» и считается отдельно от классов, которые действительно не удалось посчитать. Признак проставляется при загрузке, поэтому до первой перезагрузки конфигурации на этой версии отчёт о движениях документов будет помечен как непроверенный — это честное «данных пока нет», а не потеря результата; перезагрузка этого выпуска и так требуется. Дальше признак меняется только тогда, когда способ сбора данных действительно изменился, — рядовое обновление Analyzer перезагрузки конфигураций не потребует.
Нехватка памяти при загрузке больше не выглядит беспричинным обрывом
Загрузка конфигурации масштаба «1С:ERP Управление предприятием» держит в пике более 16 ГБ оперативной памяти. Когда её не хватало, операционная система снимала процесс без сообщения об ошибке: журнал загрузки обрывался на полуслове, и причину искали где угодно, чаще всего в свободном месте на диске. Теперь Analyzer перед началом загрузки проверяет доступный объём памяти и, если машина тесновата для крупных конфигураций, предупреждает об этом в журнале и называет рекомендуемый объём. Загрузка при этом продолжается: заранее предсказать потребность конкретной конфигурации нельзя, и отказ в запуске остановил бы прогоны, которые прошли бы успешно. Требования к оперативной памяти в инструкции по установке приведены в соответствие с замерами на реальной конфигурации.
Перезагрузка систем: ТРЕБУЕТСЯ — сверка версий научилась видеть текст модуля вне процедур, а состав объекта пополнился стандартными реквизитами и реквизитами, добавленными расширениями. Сторона, разобранная прежней версией, этих данных не несёт: до перезагрузки систем и поставок новые сравнения и ответы агенту по составу будут неполными (Analyzer честно помечает такие стороны, а не выдаёт отсутствие данных за отсутствие изменений).
Новое
Сверка версий видит текст модуля вне процедур
Раньше сравнивались только тела процедур и функций, а всё между ними — шапка модуля, директивы препроцессора, переменные уровня модуля, код инициализации — не попадало в сверку вовсе: Конфигуратор показывал модуль изменённым, Analyzer молчал. На паре соседних поставок ЗУП так терялись все изменения по Задачам и Бизнес-процессам. Теперь у изменённого модуля появляется подчинённый «Вне процедур» с окном сравнения. Правка одних комментариев (например, год в строке авторских прав) распознаётся как «только представление» и не выдаётся за содержательную: дерево сверки не тонет в тысяче модулей, отличающихся одной строкой шапки.
Паспорт объекта для агентов: весь состав одним вызовом
Инструменты подключённых агентов (MCP) отдают объект целиком за один запрос: реквизиты с типами, табличные части отдельно от шапки, формы, предопределённые элементы, значения перечислений, регламентное задание, свойства шапки и происхождение объекта (типовой, от расширения, заимствованный). В состав вошли и стандартные реквизиты платформы с русскими представлениями — без них агент ставил отборы по памяти, а не по факту, — и реквизиты, добавленные расширениями, с пометкой, какое расширение их внесло. Несколько объектов запрашиваются одним вызовом по списку ключей.
Состав функциональных опций — одним запросом для внешних систем
У инструмента функциональных опций появился обратный обход: по имени опции — объекты, которыми она управляет, а в списочном режиме — состав всех опций сразу одним запросом. Раньше внешней системе для карты «опция — объекты» требовались сотни запросов подряд, и на большой конфигурации сбор обрывался по времени.
Улучшения
Поиск объекта сообщает, насколько точно нашёл
Агентский поиск объекта помечает выдачу качеством совпадения — точное имя, совпадение синонима или похожее написание, — а не отдаёт безликий список. Запрос к системе, которой нет, отвечает ошибкой с перечнем доступных систем, а не пустым списком, из которого агент делал вывод «объектов нет».
Начало загрузки больше не молчит
Первая фаза загрузки — распаковка поставки и разбор подсистем — показывает пульс работы в журнале. Раньше на крупной конфигурации она минутами не подавала признаков жизни, и было не понять, идёт загрузка или зависла.
Исправление ошибок
Решение «оставить моё» доезжает до настроек обновления поставки
В выгрузке настроек попроцедурного объединения ручной выбор пользователя мог потеряться: объект, помеченный «не трогать», всё равно получал предписание взять модули из поставки, а решение «сохранить основное» по отдельной функции молча отдавалось правилу модуля. Конфигуратор получал предписание, обратное выбору человека. Теперь пометка объекта побеждает, решения по функциям выгружаются явно, а правило модуля наследует решение по объекту.
Повреждённый файл одного объекта расширения не роняет загрузку целиком
Если в исходниках расширения один объект оказался с повреждённым описанием (реальный случай — закоммиченные маркеры неразрешённого конфликта git), загрузка падала в конце, теряя результат всех отработавших фаз. Теперь такой объект грузится частично — имя и код модулей сохраняются, — а потеря названа в журнале загрузки; остальные объекты не страдают. Заодно объект расширения с пустым списком свойств больше не остаётся без синонима.
Обезличенное авторство: один разработчик больше не выглядит двумя, почта не показывается
Разработчик, подписанный в git по-разному (например по-русски и латиницей с одной почтой), в обезличенном авторстве получал два псевдонима: шапка говорила «Автор 1 · 85 строк», а подписи строк делили те же строки между «Автор 1» и «Автор 2». Теперь псевдоним даётся человеку, а не подписи в коммите. Заодно из обезличенного вида убрана почта — прежде имя скрывалось, а почта оставалась.
Обезличивание больше не разделяет одного человека на двух авторов
В обезличенной истории функции удалённая строка подписывалась «удалил: Автор 2» рядом со строками «Автор 1» того же коммита — один человек выглядел двумя. Причина: у части записей истории не хватало почты, по которой Analyzer и опознаёт человека (в git один и тот же разработчик подписывается по-разному), и такая запись получала отдельного «автора». Теперь человек опознаётся одинаково во всей выдаче.
Стороны трёхстороннего сравнения раскладываются по номеру релиза, а не по дате загрузки
Отметив живую конфигурацию и две поставки, можно было получить «Старую» с релизом НОВЕЕ, чем «Новая»: роли назначались по дате регистрации поставки в Analyzer, а её заводят в любом порядке. Сравнение при этом молча шло в обратную сторону — добавленное вендором показывалось как удалённое, с рекомендацией «Сохранить основное». Теперь стороны раскладываются по номеру релиза (по дате — только если номера сравнить нельзя, например у разных линеек), а если роли переставили руками наоборот, рядом с ними об этом сказано.
Предупреждение «стороны разобраны разными версиями парсера» больше не горит на свежих поставках
Загруженная поставка не запоминала, каким разбором её прочитали, поэтому считалась прочитанной самой старой версией — и трёхстороннее сравнение показывало предупреждение всегда, даже сразу после загрузки. Перезагрузка не помогала. Теперь версия разбора записывается при загрузке поставки, и предупреждение означает настоящее расхождение. Поставки, загруженные раньше, признак не получают задним числом: чем их читали, неизвестно — их нужно загрузить заново.
Функция, которую вы не меняли, больше не получает совет «объединить с приоритетом поставщика»
Если поставщик изменил функцию, а в вашей конфигурации она осталась прежней, но её подменяет перехват расширения (&Вместо без ПродолжитьВызов, &ИзменениеИКонтроль), сверка помечала её конфликтом и советовала объединение с подписью «функцию изменили и вы, и поставщик» — хотя вашей правки там нет. Теперь для основной конфигурации рекомендуется «Взять из поставки», а конфликт остаётся предупреждением: обновить нужно сам перехват в расширении. Такая функция больше не считается вашей доработкой при выборе режима для объекта-владельца.
Смена регистра букв в истории функции не выдаётся за правку
Автоформатирование приводит `Для каждого` к `Для Каждого`, а `ИЛИ НЕ` к `Или Не`; в 1С это один и тот же код, но история показывала строку удалённой и добавленной заново, с фамилией автора. Теперь регистр вне кавычек считается форматированием — как отступ и выравнивание. Внутри кавычек регистр по-прежнему значим: там лежит текст, который увидит пользователь.
При переходе на другую базу списки больше не выглядят пустыми
Сразу после смены базы в разделе «Версии» иногда пропадали загруженные конфигурации поставщиков — список показывался пустым, и возвращала его только перезагрузка страницы. Причина: первый запрос к новой базе успевал уйти с веткой прежней, а данных по такой ветке нет. Теперь ветка относится к своей базе и в запросы про другую не попадает; если выбранной ветки действительно нет, Analyzer говорит об этом прямо, а не показывает пустоту.
Смена ветки обновляет то, что на экране
Выбор другой ветки перечитывает открытую плашку целиком: раньше менялась только левая часть, а справа оставались данные прежней ветки — в «Версиях» её список версий, в остальных разделах её состав. То же самое после перезагрузки базы: плашка показывает свежий граф, а не тот, что был до загрузки.
Строка текущего состояния описывает выбранную ветку, а не активную
В разделе «Версии» строка «Текущее состояние» показывала ветку, коммит, число функций и объектов активного графа базы — при любой выбранной ветке. Числа выглядели правдоподобно, поэтому подмена не бросалась в глаза: выбрав ветку с другим составом, вы всё равно видели состав активной. Теперь и подпись, и счётчики, и размер данных относятся к той ветке, которую вы смотрите.
Перезагрузка систем: ТРЕБУЕТСЯ — изменилось внутреннее устройство графа: объект конфигурации стал в нём отдельной сущностью, и связи объекта пересобираются загрузкой. Пока база не перезагружена, дерево типов у неё останется пустым; Analyzer помечает такие базы в списке систем и говорит об этом прямо над деревом.
Новое
Видно, кто и когда написал каждую строку кода
В окне функции появились «Авторство» и «История». Авторство подписывает каждую строку: кто её написал, когда и каким коммитом. История показывает, как функция менялась — что добавлено, что удалено, кем и когда, со значками + и − и подсветкой кода. Автор ищется внутри выбранной ветки, а не среди всех участников репозитория, поэтому в ветке разработчика видно его правки. Сдвиг отступа, выравнивание по колонке и перенос строки не выдаются за правку — это форматирование. Строку, которую удалили и вернули, Analyzer подписывает исходным автором, а не тем, кто её вернул. Если правка сделана перехватом расширения, авторство и история есть и у него, а в окне функции можно переключаться между оригиналом и переопределениями. Номер задачи из сообщения коммита становится ссылкой на трекер — адрес задаётся в настройках базы. Имена авторов можно обезличить одной настройкой, и включается она до просмотра, а не после. Если файла модуля в рабочей копии нет, Analyzer пишет, какой именно файл искал и в какой копии, — по этой строке причина видна сразу.
Дорожка коммитов модуля для агента Reflexor
Analyzer отдаёт построчную раскраску файлов модуля — каким коммитом сделана каждая строка, со сверкой соответствия текста базы и репозитория. Агент Reflexor рисует по ней слева от кода в Конфигураторе цветную дорожку: у каждого участка видно, кто, когда и какой задачей его внёс; в комплект Analyzer входит обновлённый агент Reflexor.
Авторство всех функций модуля одной конечной точкой — для агента Reflexor
Агент Reflexor подписывает функции открытого в Конфигураторе модуля авторством из истории git: основной автор, последний правивший и дата — у правого края области редактирования. Analyzer отдаёт авторство всего модуля одним расчётом (blame файла один раз на все функции), ответ запоминается и переживает обновления репозитория.
Сравнение двух систем и версий прямо в интерфейсе
Вторая сторона сравнения выбирается каскадом «система → версия»: можно сравнить поставку из .cf с git-системой, версию с версией или что угодно с текущим состоянием; отмена сбрасывает результат, а не оставляет его на экране. Сверка показывает не только изменившиеся объекты и функции, но и СВЯЗИ — какие вызовы, ссылки и права появились, пропали или изменились. Вопрос «вендор убрал метод, на котором висел мой перехват» получает ответ до обновления, а не после. Стороны, прочитанные разными версиями разбора, помечаются: различия парсеров больше не выдаются за правки вендора.
Каждый работает со своей веткой одной базы
Ветка выбирается в списке рядом с выбором системы и действует только у вас: коллега в это же время может смотреть другую ветку той же базы, и никто никому не мешает. Раньше переключение ветки было общим — сменивший её менял картинку сразу всем. Выбор запоминается отдельно для каждой базы и попадает в адрес страницы, поэтому ссылку с нужной веткой можно отправить коллеге. Пустое значение означает ветку по умолчанию, её выбирает сервер. Ветка, графа которой ещё нет, подписана в списке прямо: выбор такой ветки не подменяет картинку молча, а предлагает собрать её граф.
Ветки обновляются сами, по расписанию
В настройках базы появился раздел «Загрузка из git»: адрес репозитория, токен доступа, список веток и периодичность. Включите «Обновлять ветки по расписанию» — и Analyzer сам будет забирать коммиты и перезагружать те ветки, где они появились. Обновляются ветки из списка; оставьте его пустым — и обновляться будет рабочая ветка копии. Помните про цену: у каждой ветки свой полный граф, поэтому база растёт во столько же раз, сколько веток загружено, — на крупной конфигурации это гигабайты и часы за ветку. Если новых коммитов нет, загрузка не запускается, поэтому проверка ничего не стоит. Пока идёт одна загрузка, остальные ветки ждут очереди и не теряются. Токен хранится в зашифрованном виде и обратно не показывается — у каждой базы он свой. По умолчанию расписание выключено: без него всё работает как раньше, только вручную. Рядом с веткой в списке виден знак b88;, если последнее обновление не удалось; подробности — в журнале загрузки этой ветки.
Историю коммитов и ветки можно догрузить из настроек базы, не перезаливая систему
В настройках базы, в разделе «Загрузка из git», написано состояние истории — «полная» или «обрезана, столько-то коммитов» — и рядом стоит кнопка «Догрузить историю и ветки». Раньше это настраивалось только при первой загрузке, а сообщение об урезанной истории отсылало в форму системы, где ничего подобного не было. Догрузка идёт по всем репозиториям системы, включая расширения со своими клонами, работает фоном и не перезагружает граф. Она же приносит ветки: прежде углубление истории касалось единственной ветки, и остальные не появлялись в копии ни при какой повторной загрузке. Что именно будет догружено — перечисленные ветки или все — написано до нажатия, а после догрузки там же сказано, что графы по веткам строятся отдельно и где: принесённая ветка выбирается в списке веток и загружается по подтверждению.
Обновление по коммитам: грузится только то, что изменилось
В меню перезагрузки появился пункт обновления по коммитам: Analyzer сверяет, какие коммиты появились с момента сборки графа, и показывает дельту. Граф помнит, из какого коммита он собран, поэтому «актуален ли он» стало видимым фактом, а не догадкой.
Обращения к базе в цикле — новый класс находок
Analyzer отмечает запросы и чтения объектов внутри цикла: это классическая причина того, что обработка на тысяче строк идёт минутами. У находки виден уровень вложенности. Конструкторы наборов записей и запись в файл к обращениям к базе не относятся и не засчитываются — иначе каждая четвёртая находка была бы ложной.
Токен доступа выпускается себе без администратора
Значок ключа рядом с именем в шапке открывает окно «Мои токены доступа»: выпуск, список с датами использования и отзыв. Доступно любой роли, включая «Просмотр» — токен нужен агентам и внешним инструментам, работающим от вашего имени. Чужие токены в окне не видны; выпуск и отзыв записываются в журнал действий.
Адреса API получили версию
Канонический адрес — /api/v1/…, прежний /api/… остаётся навсегда как псевдоним: интеграции, развёрнутые у вас, продолжают работать без изменений.
Формы без кода извлекаются из бинарных поставок
Раньше из .cf и .cfe брались только формы, у которых есть модуль: формы списка, выбора и группы без кода терялись, и сверка поставок показывала их как отсутствующие. Теперь список форм читается из состава объекта, а не по наличию кода.
Журнал идущей загрузки открывается из меню перезагрузки
Раньше окно журнала видел только тот, кто сам запустил операцию из этого меню: загрузку, начатую из списка веток, с другой вкладки или другим пользователем, посмотреть было нечем. Теперь при идущей операции первым пунктом меню стоит «Идёт загрузка — показать журнал» — открывается живой хвост журнала до конца операции, а сообщение о запуске загрузки ветки называет точное место, где смотреть ход.
Проверку сертификатов git и каталога LDAP можно включить
Появились настройки для тех, кому важно, чтобы соединение подтверждало личность сервера: ANALYZER_GIT_SSL_VERIFY для загрузки конфигураций из git и ANALYZER_LDAP_TLS_VERIFY для входа через LDAP или Active Directory. Если сервер использует самоподписанный сертификат, положите корневой сертификат в папку conf и укажите путь к нему в ANALYZER_GIT_CA_FILE или ANALYZER_LDAP_CA_FILE — тогда проверка включится и будет сверяться именно с ним. Обновление ничего не меняет для тех, кто эти настройки не задаёт: поведение остаётся прежним, перенастройка не требуется.
Улучшения
Понятно, почему база выглядит пустой после обновления, и что с этим делать
База, загруженная прежней версией, до перезагрузки действительно показывает в дереве типов две-три служебные ветки вместо всего состава конфигурации: объектов конфигурации как отдельных сущностей в ней ещё нет. Данные целы, но со стороны это читается как потерянная конфигурация — и раньше никаких пояснений на этот счёт не было. Теперь такая база помечена в списке систем, а над деревом стоит объяснение и указание перезагрузить её.
Объект конфигурации виден в связях целиком, а не через свои модули
Раньше объект в базе Analyzer не существовал сам по себе: его подменял один из модулей, и всё, что описывает объект — реквизиты, формы, макеты, состав движений, права ролей, ссылки, запросы — привязывалось к этому модулю. У объекта без кода (справочник без модуля, роль, общая форма, регламентное задание) подходящего модуля не находилось, и часть сведений о нём терялась молча: на рабочей базе так пропадали свойства почти тысячи объектов из четырёх тысяч, а также права, ссылки и запросы к их таблицам. Теперь объект — самостоятельная единица, ему принадлежат его модули, формы и команды, а форме — её модуль. Прямое следствие: связей стало больше — ссылок между объектами на 12% и запросов к таблицам на 9%, и это те связи, которые прежде не показывались вовсе. Карточка объекта без единой строки кода теперь открывается и показывает свои связи.
Авторство и история функции показываются на лету
Раньше каждый показ считал историю git заново — на большом монорепо это 3–5 секунд на каждую вкладку. Теперь расчёт начинается заранее, при открытии окна функции, готовые ответы запоминаются до изменения репозитория, blame модуля считается один раз на все его функции, а первый расчёт идёт параллельно. Повторные показы открываются мгновенно, соседние функции того же модуля — в разы быстрее.
Авторство считается заранее для того, что открыто на экране
Открыли перечень функций объекта, граф вызовов или список функций модуля в графе — их авторство и история считаются в фоне, пока вы смотрите; клик по функции отвечает из готового кеша. Новый взгляд замещает прежнюю очередь: греется то, что перед глазами сейчас. Обновление репозитория по расписанию больше не сбрасывает накопленный кеш целиком — пересчитывается только то, что в действительности изменилось.
Подпись авторства помнит исходного автора
Когда строку написал один человек, а последним правил другой, в авторстве модуля появляется «изначально — кто написал». Агент Reflexor показывает это в подписи рядом с кодом в Конфигураторе. История модуля для этого прогревается заранее по самим обращениям агента — подписи появляются быстрее.
Ветки выбираются из списка, а недостающие догружаются сами
Поле «Ветки» в настройках базы стало выбором из веток репозитория — помнить имена наизусть не нужно, загруженные подписаны «граф загружен», а ветку, созданную на сервере после клона, по-прежнему можно ввести руками. Сохранили настройки с новой веткой — Analyzer сам заметит, что её нет в копии, и догрузит фоном: отдельную кнопку «Догрузить историю и ветки» нажимать больше не обязательно, она осталась для ручного повтора после сбоя.
Состояние сборки графа ветки видно прямо в списке веток
Ветка без графа больше не подписана одинаково на все случаи: в списке видно «собирается…», «в очереди (с номером — перед ней могут стоять другие задания)» и «ошибка» с причиной в подсказке при наведении — выбор такой ветки с правом загрузки запускает повтор. Пока по базе что-то собирается, список обновляет состояние сам. Загруженная ветка, которую убрали из списка наблюдения расписания, подписывается «не обновляется»: граф остаётся на месте, но его тихое устаревание перестало быть невидимым.
Долгие сверки говорят, что живы
Сопоставление с эталоном и сравнение версий на больших базах показывают ход работы: строка «идёт, столько-то секунд» раз в полминуты, честная оценка длительности по размеру базы и темп записи пометок с секундами. Сама классификация по эталонам читает из базы только необходимое — на медленных дисках это кратно быстрее.
Ветки: все приезжают в копию, конфигурация находится сама, а графы — по вашему выбору
Клон приносит все ветки репозитория, а не одну: прежде клон единственной ветки без исходников означал «нет конфигурации» при полностью исправном репозитории. Если в рабочей ветке конфигурации нет, загрузка сама перейдёт на ту, где она есть (порядок: main, master, release, dev, develop, дальше по свежести); ветки без конфигурации отсеиваются заранее, и всё это видно в журнале. Граф при этом строится по рабочей ветке: каждая ветка — это полный разбор конфигурации и свой граф в базе, на репозитории с десятками веток это десятки гигабайт и часы работы. Нужные сверх того ветки перечисляются в настройках базы — тогда их поддерживает расписание — или загружаются одним щелчком из списка веток: ветка без графа теперь выбирается, Analyzer спрашивает подтверждение, честно предупреждая о длительности, и запускает загрузку, не трогая графы остальных веток. Авторство честное и без загрузки веток: история хранится в копии, у строки из влитой ветки виден её настоящий автор и ветка-источник.
Перечислили ветки при загрузке — получите граф каждой
Раньше граф собирался только по первой ветке, а остальные молча приезжали «в копию»: пользователь без прав загрузки, выбрав такую ветку, упирался в тупик. Теперь первая ветка списка загружается сразу, остальные встают в очередь и собираются автоматически по одной; журнал говорит об этом прямо, а список веток сохраняется в настройках базы — расписание поддерживает именно его. Пустое поле, как и прежде, приносит все ветки в копию с графом по рабочей.
Ход загрузки: скорость в мегабайтах и честный остаток времени
Скорость разбора считается по объёму обработанного кода — в мегабайтах в секунду, а не по числу модулей: модули разного размера делали штучную скорость обманчивой, она «падала» вчетверо при ровной работе. Остаток времени оценивается по темпу последних полутора минут, а не по среднему с начала этапа — оценка перестала замирать на одном значении на десятки минут. Прогресс идёт плавно, без долгих пауз с последующим рывком на сотни модулей, а сообщение при длинной операции объясняет, что для крупных блоков данных это нормально.
Загрузка средних конфигураций стала быстрее почти вдвое
Разбор кода распараллеливается с меньшего размера базы: конфигурация на три тысячи модулей раньше разбиралась в один поток, потому что порог включения был подобран с запасом. Замер на складской базе: разбор кода 2 мин 55 с → 1 мин 17 с, вся загрузка 3 мин 45 с → 2 мин 35 с. Порог настраивается (ANALYZER_BSL_PARALLEL_MIN), если на вашей машине выгоднее иначе.
Загрузка объясняет, почему не нашла конфигурацию
Вместо «нет конфигурации» журнал пишет, какие раскладки проверялись и что реально лежит в папке — вплоть до ветки каждого клона и числа файлов в ней. Пустая ветка, недокачанное клонирование и незнакомая раскладка теперь различимы с первого взгляда.
Отказ доступа к репозиторию объясняется по-русски
Когда git отвечает «could not read Username» или «Authentication failed», журнал подсказывает: репозиторий требует входа — укажите токен в форме загрузки или настройках базы, проверьте срок действия и право чтения.
История версий появляется сама, без нажатий
У систем из .cf, .cfe и ZIP истории не было: загрузка новой версии затирала прежнее состояние, и сравнить «что изменилось в поставке» удавалось, только если человек заранее нажал «Зафиксировать версию». Теперь перед загрузкой новой версии прежнее состояние фиксируется само. Автоснимков хранится ограниченное число, старые убираются, а версии, зафиксированные вручную, не трогаются никогда. У git-систем история и так есть, поэтому там автофиксация не включается.
Загрузка больше не прерывает работу с базой
Раньше перезагрузка стирала данные системы перед перезаливкой, и в это окно все, кто смотрел базу, видели полупустую картину. Теперь загрузка идёт в отдельную копию, а переключение происходит одним действием в конце: до него видно прежнее состояние, после — новое.
Имена объектов показываются на нужном языке
Синоним в 1С многоязычный, а Analyzer брал первый вариант из файла: в конфигурациях, где английский идёт первым, всё дерево показывалось по-английски при наличии русских имён. Теперь язык выбирается осознанно, а порядок предпочтения задаётся в настройках базы — у англоязычной конфигурации русского синонима может не быть вовсе.
Дерево типов стало читаться как в Конфигураторе
Первой идёт «Конфигурация», за ней папка «Общие» со значком из 1C:EDT — раньше там был серый кружок, а сама папка стояла выше конфигурации. Ветка «Прочее» переехала внутрь «Общих» и больше не мозолит глаза среди справочников и документов, а её содержимое разложено по видам: «Общие картинки», «Элементы стиля», «Языки», «Группы команд», «Общие реквизиты», «Хранилища настроек» и другие — с числом объектов и значком каждого вида. На ERP в «Прочем» три тысячи объектов, из них почти всё картинки; найти среди них язык раньше было нельзя. Объекты, вид которых определить не удалось, собраны отдельной папкой в конце.
В истории функции дата у каждой правки и видимое сообщение коммита
Дата показывалась только у удалённых блоков — у живых строк того же коммита её не было. Теперь дата стоит у каждого блока и везде в одном формате ДД.ММ.ГГГГ (раньше история писала «2023-11-28» рядом с «14.09.2023» авторства), а сообщение коммита видно прямо в подписи (длинное обрезается, целиком — в подсказке; номера задач внутри — ссылками). Подписи авторства и истории выглядят одинаково.
Журнал загрузки читается по-русски
Шаги и счётчики назывались служебными именами связей графа — «Posting summary документов», «Опции: controls (состав)», «DefinedType: composes_type», «Impact: triggers_subscription». Теперь у каждого шага человеческое название: «Движения документов из кода проведения», «Функциональные опции: чем управляют», «Определяемые типы: состав», «Влияние: срабатывание подписок». Построчная раскладка очистки коллекций убрана — осталась итоговая строка, а подробности включаются переменной ANALYZER_VERBOSE_CLEANUP для разбора проблем.
Исправление ошибок
Пустые строки в дорожке коммитов не выдаются за чужую правку
Пустая строка внутри участка одного коммита раскрашивается, как её окружение, а не как отдельная правка слияния — дорожка читается сплошными участками, без ложных вкраплений.
Повторная загрузка из git не выглядит новым клонированием
Журнал теперь первой строкой говорит, что существующая копия найдена и качаются только новые коммиты — на большом репозитории это разница между минутой и часом ожидания, и раньше её приходилось угадывать. Копия, застрявшая под временным именем после неудачного переименования, чинится при следующей загрузке сама, а разбор больше не спотыкается о папку незавершённого клона. Запустить клонирование поверх идущей загрузки теперь нельзя: раньше оно затирало отметку о занятости и журнал идущей работы.
Повреждённый файл выгрузки больше не срывает загрузку всей конфигурации
Один оборванный XML — незавершённая выгрузка, обрыв копирования — останавливал разбор конфигурации целиком, причём сообщение не называло, какой файл виноват: чинить было нечего. Теперь такой файл пропускается, а в журнале видно его имя, место обрыва и вероятная причина; в конце разбора выводится итог: сколько файлов повреждено и что объекты из них в графе отсутствуют. Загрузка доходит до конца на исправной части конфигурации.
Журнал загрузки читается по порядку
Часть шагов загрузки выполняется одновременно, и в журнале их номера шли вразнобой — после сорок пятого мог появиться двадцать восьмой, будто загрузка вернулась назад. Теперь такие шаги объединены в блок с общим диапазоном номеров и подписью, что они идут одновременно и завершаются в произвольном порядке; внутри блока каждый шаг отмечается по мере готовности.
Обновление по расписанию больше не портит файлы идущей загрузке
Расписание забирало коммиты из git, не помечая базу занятой, — и запущенная в этот момент вручную загрузка читала файлы, которые git прямо в этот момент перезаписывал. Итог выглядел как случайно испорченная выгрузка: разбор падал на произвольном файле. Теперь на время работы с git база помечается занятой, и ручная загрузка честно сообщает, что нужно дождаться завершения.
Эталон поставщика размечает все ветки базы
Эталон назначается базе, а не тому, кто его назначил, и не ветке, случайно открытой в этот момент. Раньше пометки «типовая / доработана» появлялись только в той ветке, что была активной во время пересчёта: коллега на соседней ветке видел неразмеченный код и справедливо считал, что сверка не сработала. Теперь пересчёт проходит по всем загруженным веткам базы — активная первой, чтобы её не приходилось ждать, — а в журнале видно состав веток и номер текущей.
Открытая страница не пустеет из-за фоновой загрузки
Пока вы смотрите объект, расписание могло перезагрузить базу — и клик по модулю отвечал «Нет данных» при непустом счётчике функций в шапке. Данные были на месте: страница обращалась к предыдущей версии графа. Теперь такое обращение исправляется само, и обновлять страницу не нужно.
Изменения в расширениях с отдельным репозиторием больше не теряются
Если конфигурация и её расширения лежат в разных репозиториях, Analyzer теперь проверяет их все: правка расширения приводит к обновлению базы, а не к ответу «перезагружать нечего». Переключение на ветку тоже применяется ко всем репозиториям системы, где такая ветка есть.
Графы веток не пропадают из-под работающих
Перезагрузка одной ветки больше не может убрать графы остальных веток той же базы — даже если у загруженного графа ветка не указана (так бывает у баз из архива или бинарной поставки). Кроме того, граф, который открывали в последние сутки, при уборке сохраняется, даже если он уже не самый свежий: если им пользуются, значит он нужен. Сколько графов держать на каждой ветке и сколько суток хранить после последнего обращения — настраивается (ANALYZER_KEEP_GENERATIONS_PER_BRANCH и ANALYZER_KEEP_USED_DAYS): когда с базой работают несколько человек, полезно оставлять и предыдущий граф.
Авторство находит файл в любой раскладке репозиториев
Авторство и история искали файл модуля только в одном репозитории системы. Если конфигурация склонирована в подпапку базы или расширения лежат отдельными репозиториями, файл не находился — и отказ ссылался на расширение даже там, где никаких расширений нет. Теперь просматриваются все репозитории базы, а история читается из того же, где найден файл.
Разбор кода больше не замирает молча
Пул разбора кода переведён на другой способ запуска рабочих процессов: прежний на части машин приводил к тихой остановке — загрузка стояла без единого слова в журнале, а все процессы спали. На эталонном прогоне (27 тысяч модулей) новый способ оказался ещё и быстрее всех прежних замеров, зависаний — ноль.
Загрузка большой конфигурации из git больше не обрывается по таймауту
Обновление рабочей копии ограничивалось двумя минутами: на крупной конфигурации git не успевал, загрузка молча продолжалась на исходниках, которые уже лежали на диске, и отчитывалась как успешная — граф собирался из вчерашнего состояния, выглядя свежим. Предел поднят до получаса и распространён на переключение веток, чтение состава репозитория, клонирование (там git считался повисшим после двух минут молчания, хотя на большом репозитории пауза дольше нормальна) и обновления по расписанию; для медленных каналов настраивается переменной ANALYZER_GIT_TIMEOUT.
Неудачные обновления из git больше не съедают диск
Когда git прерывался по времени, недокачанные данные оставались на диске, и каждая следующая попытка добавляла новые: на большом репозитории это отняло у клиента больше 100 ГБ за полдня. Теперь Analyzer убирает такие остатки сразу и перед каждой новой попыткой, а прерванная попытка честно записывается как неудача и не мешает следующим.
Повторная загрузка из git снова читает конфигурацию
Если систему грузили из того же репозитория повторно, Analyzer забирал свежие коммиты, писал «Загрузка завершена» — и на этом останавливался: конфигурация не перечитывалась, граф оставался прежним. Со стороны это выглядело как успешная загрузка, после которой ничего не изменилось, а сама база вдобавок числилась «только в графе, без папки». Теперь разбор идёт и после обновления рабочей копии, а не только после первого клонирования.
Повторная загрузка перестала терять доступ к репозиторию
Если поле токена оставляли пустым (он ведь уже сохранён), Analyzer переписывал адрес репозитория без учётных данных, и следующая же загрузка падала с отказом авторизации. Теперь пустое поле означает «взять сохранённый токен», а не «ходить без него». Заодно токен подставляется и в адреса http:// — репозитории в контуре заказчика часто поднимают без шифрования, и такой адрес оставался без доступа. Углубление истории и добор веток выполняются, даже если обновление рабочей копии не удалось: одно от другого не зависит.
Загрузка большой конфигурации доводится до конца, даже если разбор кода срывается
Разбор модулей идёт несколькими процессами, и обрыв связи с ними прекращал загрузку целиком: система не загружалась вовсе. Теперь Analyzer доразбирает оставшееся сам — медленнее, но до конца. Проверено на живой базе: три подряд сбоя разборщика, загрузка завершилась полностью и с тем же результатом.
Итог долгого клонирования не теряется из-за занятой папки
Финальное переименование папки клона повторяется, пока её держит антивирус или индексатор: раньше единственная неудачная попытка отменяла результат часового скачивания. Если загрузка всё же завершилась ошибкой, журнал заканчивается честной строкой о сбое, а не «Загрузка завершена!».
Полнота состава возврата у функций, вызывающих друг друга
Если две функции вызывают друг друга, состав возвращаемой структуры у них теперь общий. Раньше одной из них доставалась лишь часть полей, и какая именно — зависело от порядка обхода, поэтому состав менялся между загрузками одного и того же кода: у одной из таких функций было 6 полей вместо 23.
В графе «Кто вызывает» виден полный охват, а не только показанное
У служебной функции вызывающих бывают тысячи, и на схему они не помещаются. Теперь под статистикой видно, сколько прямых вызывающих всего, сколько из них попало на схему, в скольких модулях и подсистемах они лежат и какие модули зовут функцию чаще других. Прежде список выглядел полным, не будучи им.
Удалённые строки в истории функции стоят на своём месте
Раньше кусок, у которого изменилась строка-сосед сверху, уезжал в конец с пометкой «место в теле не определено» — выглядело, будто строки удалили вне процедуры. Теперь место ищется по нескольким соседним строкам сверху и снизу, побеждает ближайшая к куску — заменённая строка встаёт вплотную к своей замене, а не через пустую строку выше. На живой функции с активной историей все удаления встают в тело.
Адрес трекера задач действует сразу после сохранения
Ссылки на задачи в авторстве и истории появлялись только после обновления страницы — только что введённый адрес выглядел неработающим. Теперь сохранение настроек применяет его немедленно.
Поле кода в авторстве заканчивается на последней строке
У короткой функции тёмная область кода больше не тянется пустой до низа окна — оба вида кода (авторство и история) заканчиваются там, где кончается функция. Длинная функция, как и раньше, прокручивается при неподвижной шапке.
Удаление базы забирает всё её хозяйство
Вместе с базой теперь удаляются все её версии — ручные, автоснимки и загруженные поставки с их графами, — а также сессии объединения, настройки с токеном доступа и задания расписания. Раньше часть этого оставалась в базе данных и продолжала жить своей жизнью: расписание, например, пыталось обновлять удалённую базу.
Сообщения о загрузке ветки — в тёмной теме
Всплывающее сообщение и окно подтверждения при загрузке ветки выходили светлыми на тёмном интерфейсе; теперь они в стиле приложения.
Окно журнала загрузки честно говорит, когда журнал занят другой операцией
Окно, чей запуск вытеснен новой загрузкой, молча замирало на последних строках — неотличимо от зависания. Теперь оно останавливает опрос и показывает плашку «журнал перешёл к другой операции — откройте заново». Возврат на вкладку из фона сразу дозапрашивает журнал, финал загрузки больше не пропускается.
Окно загрузки больше не показывает чужой текст в первые секунды
Журнал операции один на все действия — загрузку, клонирование, сравнение версий, — и при запуске новой загрузки окно успевало мигнуть хвостом предыдущей. Теперь окно ждёт свою операцию и показывает только её.
Настройки базы помещаются в окно целиком
Раздел «Загрузка из git» уезжал за нижний край, и до него добирались только прокруткой. Теперь окно в две колонки — «Отображение» и «Загрузка из git» — и видно сразу всё.
Перезагрузка систем: ТРЕБУЕТСЯ для систем, загруженных из бинарного .cf/.cfe — чтобы Analyzer снял отпечатки структуры форм и состав движений документов, без них сравнение форм и часть проверок обновления работают не в полную силу. Для систем из выгрузки конфигурации и EDT перезагрузка не требуется.
Изменения
Риски обновления: что именно сломается после объединения с поставкой
Новая панель в режиме «Версии» собирает семь классов рисков в одном месте: движения документа в регистр, где он не значится регистратором; правки расширения вне директив вставки и удаления (такие правки просто не применяются); перехваты, которые перестанут работать после изменения метода вендором; реквизиты, снятые вендором и используемые расширением; переопределённые формы; составные типы и заимствованные объекты. По каждому классу — список находок с причиной и переходом к объекту.
Риск показывается на той строке, к которой относится
Пометка «b88;» стоит там, где проблема: у самой функции — перехват под изменением вендора, у самого реквизита — снятие вендором с указанием, сколько раз к нему обращается расширение, у объекта — то, что относится к объекту целиком. Раньше пришлось бы искать нужную строку среди десятков реквизитов или семидесяти функций модуля.
Отбор дерева сверки по рискам обновления
Флажок «Только с рисками обновления» оставляет в дереве объекты, которых обновление коснётся. Если таких в поставке нет, Analyzer так и говорит числами, вместо того чтобы показывать пустое дерево без объяснения.
Сравнение форм из бинарной поставки
Из бинарного контейнера теперь снимается отпечаток структуры формы, поэтому переопределённые расширением формы сравниваются по существу. Раньше по таким формам Analyzer честно отвечал «проверить не смог», и все находки уходили в этот разряд.
Analyzer больше не приписывает пользователю чужие правки
Служебные пометки, которые Analyzer добавляет при чтении бинарной поставки, перестали показываться как содержимое формы. Кроме того, если система и поставка прочитаны разными версиями программы, форма сверки предупреждает об этом прямо над деревом: состав объектов в таком случае сравнивать нельзя, нужна перезагрузка системы. До этого расхождение выглядело как «этот элемент меняли только вы» на объекте, которого никто не трогал.
Ширину колонок можно менять во всех таблицах
Любая колонка тянется за правый край заголовка, ширина запоминается. Длинные имена 1С перестали уходить под многоточие именно там, где начинается отличие.
Понятная форма сверки версий
Кнопки разделены на три группы по смыслу — сравнение, откуда берутся версии, что с чем сравнивается; порядок ролей стал «моя · старая · новая»; список версий вместе с выбором сторон убирается с экрана одной кнопкой, оставляя строку-напоминание. В выпадающем списке систем первой идёт папка, а в колонке «Линейка» отдельно показаны расширения поставки — раньше одинаковые на вид записи было не различить.
Расчёт рисков ускорен втрое
Подготовка данных для всех классов рисков идёт один раз вместо пяти, результат запоминается: на ERP с семьюстами тысячами функций расчёт сократился с 82 до 29 секунд, повторное открытие — мгновенно.
Исправления
Устранено падение всей формы сверки при раскрытии узла дерева; починена регистрация поставки для конфигураций с журналами документов; выбор версий и загрузка поставки перестали показывать внутренние идентификаторы вместо имён.
Перезагрузка систем: не требуется (само приложение не менялось, обновлено только вложенное окно-компаньон).
Изменения
Окно-компаньон Конфигуратора стало вдвое легче
Приложение-компаньон, которое поставляется вместе с Analyzer, уменьшилось с 42 до 26 мегабайт: из комплекта убраны библиотеки, которые оно не использует. Работает по-прежнему, обновление — заменой распакованной папки.
Перезагрузка систем: ТРЕБУЕТСЯ для систем, загруженных из бинарного .cf/.cfe — чтобы подхватить новый состав функциональных опций, команд объектов и подсистем. Для систем из выгрузки конфигурации и EDT перезагрузка не требуется.
Изменения
Обратный граф вызовов: «Кто вызывает функцию»
Для любой функции теперь строится цепочка в обратную сторону — кто её вызывает, на несколько уровней вверх, с таблицей прямых вызывающих и переключателем направления графа. Помогает заранее оценить, что затронет правка функции.
Полный состав объектов из бинарного .cf: функциональные опции, команды, подсистемы
При загрузке из бинарного контейнера (.cf/.cfe) Analyzer теперь извлекает состав функциональных опций (какие объекты, реквизиты, табличные части и команды опция включает), команды объектов и состав подсистем. Раньше у бинарных систем эти сведения были неполными или пустыми; теперь состав совпадает с тем, что даёт выгрузка конфигурации.
Окно-компаньон рядом с Конфигуратором
Analyzer умеет работать не только встроенным в 1C:EDT, но и окном-компаньоном рядом с Конфигуратором: окно следует за выбранным в дереве объектом и показывает его связи, код функций и переопределения расширений. Встраивание обобщено под обе среды разработки.
Точность по расширениям при частичной перезагрузке
Перезагрузка только расширений («Перезагрузить расширения») теперь даёт те же данные, что полная: восстанавливаются функции и формы новых объектов расширений, права ролей на подсистемы, модули HTTP- и Web-сервисов и общих команд расширений; убраны лишние «пустые» объекты подсистем.
Понятный ход загрузки и честный статус при сбое
Журнал загрузки идёт ровно по шагам, добавлен сторож «тишины» и внятное сообщение при переполненном диске базы вместо зависания; при падении показывается честный статус, а не молчаливый обрыв.
Исправления интерфейса
Карточка объекта, у которого связи — только роли, больше не показывает пустую таблицу при непустом счётчике; «Показать функцию» работает в окне-компаньоне; после обновления приложения интерфейс всегда подхватывает свежую версию (устранено залипание на старой странице).
Перезагрузка систем: не требуется (изменения касаются только входа и управления пользователями).
Изменения
Проверка входа пользователя по LDAP
У пользователя из каталога (LDAP/Active Directory) в списке появилась кнопка «Проверить»: она без пароля находит пользователя в каталоге, показывает его группы и сверяет их с правилами «группа → роль». Сразу видно, почему вход не проходит — например, группа пользователя не указана ни в одной роли или записана в другой форме имени. Подсказывает, что именно поправить.
Роли для групп LDAP и единого входа задаются в интерфейсе
Соответствие «группа → роль» (для LDAP) и «значение claim → роль» (для единого входа OIDC) теперь настраивается прямо на вкладках раздела «Пользователи»: для каждой роли вписываются группы, которые её дают. Изменения применяются сразу, без перезапуска. Раньше это соответствие задавалось только в настройках окружения.
Встроенный администратор защищён от изменений
У встроенного администратора нельзя сменить пароль, роль и активность через интерфейс, а также удалить его — эти параметры задаёт владелец в настройках окружения. Это исключает случайную потерю доступа к управлению.
Перезагрузка систем: РЕКОМЕНДУЕТСЯ (исправление функций-тёзок и тел перехватчиков расширений меняет схему ключей: полный эффект — после перезагрузки конфигурации и перерегистрации поставок; без перезагрузки всё работает по-старому).
Изменения
Единая группировка формы в сверке версий
Функции формы теперь показываются под той же группой «Форма X», где её реквизиты и свойства, а не отдельной веткой — состав формы и её обработчики собраны вместе. Группы форм и модулей сворачиваются, у группы есть массовые действия «Взять всё из поставки» и «Подтвердить все».
«Прочие» объекты разложены по своим типам
Хранилища настроек, общие картинки, элементы стиля, языки, нумераторы, группы команд и другие виды, раньше сваленные в узел «Прочие», теперь идут каждый в своём типе метаданных с понятным названием.
Тела переопределений расширений в окне кода
Панель «Переопределения в расширениях» показывает тело перехватчика (&Перед/&После/&Вместо/&ИзменениеИКонтроль) — раньше у части перехватов тело было пустым. Работает во всех форматах загрузки.
Отзывчивость дерева сверки
Дерево сверки версий больше не подтормаживает при сворачивании списка версий, открытии окна кода и других действиях; при длительной фильтрации показывается индикатор «Идёт применение фильтра». «Свернуть всё» сворачивает дерево целиком, включая раскрытые объекты.
Читаемость дерева сверки
Объекты-тёзки (одинаковый синоним у разных типов, например «Прочие доходы» у регистра и журнала документов) различаются по символьному имени в скобках. Переименованные объекты помечаются значком изменения, а не добавления, с корректной подсказкой. Убрано служебное свойство «Двоичная шапка», не относящееся к Конфигуратору.
Модули приложения и сеанса в сверке
Модуль управляемого/обычного приложения, модуль сеанса и модуль внешнего соединения теперь разбираются во всех форматах загрузки (включая бинарные .cf — раскладка сверена побайтно с выгрузкой той же конфигурации) и участвуют в сверке версий: правки поставщика в этих модулях видны в дереве под узлом «Конфигурация». Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Изменение порядка в сверке версий
Перестановка реквизитов и движений документа (без добавлений/удалений) видна отдельной строкой «↓↑ Порядок» с указанием, кто переставлял; решение выгружается в файл настроек Конфигуратора тегом порядка. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Отчёт о сравнении
Кнопка «Отчёт о сравнении» внизу дерева сверки скачивает самодостаточный HTML-файл: сводка по категориям и полный список различий по типам, объектам, их составу и функциям — для печати или передачи коллегам. Аналог отчёта о сравнении Конфигуратора.
Свойства реквизитов в сверке версий
Изменения свойств реквизитов, измерений и ресурсов (подсказка, формат, маска, значение и проверка заполнения, ведущее, основной отбор и пр.) видны в раскрытии объекта строкой «свойство: было → стало» с указанием, чья правка. Дефолтные значения не сравниваются; действует для выгрузок в файлах (XML), из бинарных поставок свойства реквизитов не извлекаются. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Настройки обновления поставки (выгрузка для функции «Обновление конфигурации»)
Кнопка «Настройки обновления поставки» (при трёхстороннем сравнении) скачивает файл настроек для штатной функции 1С «Обновление конфигурации на поддержке» — с тремя конфигурациями (моя, новая поставка, старый эталон вендора). Главное отличие от файла объединения: модули объединяются попроцедурно — по каждой изменённой процедуре готовится точечная правка, а не слияние модуля целиком. Для бинарных поставок, где тела процедур недоступны, модуль объединяется целиком.
Перехват свойств заимствованного объекта расширением в сверке версий
Если расширение заимствует типовой объект и контролирует его свойства (проведение, длина кода и пр.), это видно в сверке: строка свойства помечается «c98; перехвачено: <расширение>», а смена этого свойства поставщиком отмечается как конфликт — обновление затронет то, что контролирует расширение. По образцу перехвата процедур расширениями. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Значения перечислений в сверке версий
Добавление, удаление и изменение порядка значений перечисления (EnumValue) видны в раскрытии объекта: строка «значение» с маркером добавлен/удалён и отдельная строка «↓↑ Порядок» вида «Значения», когда значения переставлены. Действует для выгрузок в файлах (XML и EDT). Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Реквизиты адресации задач и описатели форм в сверке версий
Реквизиты адресации задач (например у «Задачи исполнителя») теперь участвуют в сравнении наравне с обычными реквизитами — с пометкой «адресация». У форм и макетов сверяется описатель (синоним, назначения использования, комментарий, тип макета) отдельно от содержимого — изменение видно строкой «Свойство формы: было → стало». Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Свойства конфигурации в сверке версий
Свойства корня конфигурации (режим совместимости, вариант встроенного языка, основные роли, режим запуска, авторские права, адреса поставщика и пр.) вошли в сравнение: изменения видны под узлом «Конфигурация» строками «Свойство: было → стало». Работает во всех форматах загрузки; для бинарных поставок дополнительно сверяется отпечаток двоичной шапки корня. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Составы общих реквизитов и планов обмена в сверке версий
Изменение состава общего реквизита (включая области данных) и состава плана обмена вошло в сравнение: в раскрытии объекта строка «Состав» показывает добавленные и удалённые элементы, а у изменённых — смену режима (Авто/Использовать/Не использовать, Разрешить/Запретить авторегистрацию) с указанием, чья это правка. Действует для выгрузок в файлах (XML и EDT); из бинарных поставок состав не извлекается. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Свойства объектов в сверке версий
Свойства «шапки» (проведение, нумерация, иерархия, длины кодов, синонимы, представления, режимы блокировки и пр.) вошли в сравнение: изменённое свойство помечает объект и показывается строкой «Свойство: было → стало» с указанием, чья правка — ваша или поставщика. Для бинарных поставок дополнительно сверяется отпечаток двоичной шапки (факт изменения свойств без расшифровки). Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Движения документов в сверке версий
Состав движений (настройка документа «Движения», по каким регистрам разрешена запись) вошёл в сравнение: изменение состава помечает документ изменённым, в раскрытии видно «Движения: добавлен/удалён регистр» с рекомендацией и указанием, чья это правка — ваша или поставщика. Читается из всех форматов, включая бинарные .cf поставок. Эффект — после перезагрузки конфигурации и перерегистрации поставок.
Исправлена коллизия функций-тёзок (различие только «_»)
Функции, имена которых различаются только подчёркиванием (например «РасчетПоказателей_РегламентированныйОтчетЕФС1ОСС» и «РасчетПоказателейРегламентированныйОтчетЕФС1ОСС»), больше не затирают друг друга: обе живут в графе (анализ функций, граф вызовов) и корректно сверяются с поставкой — ложные «Конфликт»/«моё изменено» при идентичных телах уходят. Ключи прочих функций не меняются. Эффект — после перезагрузки конфигурации, затем перерегистрации поставок (именно в этом порядке).
Окно хода работы для долгих действий сверки версий
Назначение эталона, сравнение версий и обновление поставки показывают окно-журнал с живыми шагами (что именно делается и сколько обработано) вместо немого ожидания; при ошибке окно остаётся открытым с причиной. Строки журнала не задваиваются, когда сервер отвечает медленнее опроса.
Версия вендора у поставок
У вендорской поставки в списке «Версии» показывается версия из корня файла поставки (например 3.1.34.253) — несколько поставок одной линейки теперь различимы; версия заполняется у поставок, загруженных начиная с этой версии. Она же видна в селекторах ролей База/Новая/Моя (первой, до имени конфигурации) и в раскрытом списке ролей.
Режимы объединения по наличию сторон
Для элемента, которого нет в новой поставке, предлагаются только «Сохранить (в поставке нет)» и «Удалить (как в поставке)»; для элемента только из поставки — «Взять из поставки» и «Не добавлять». «Объединить с приоритетом…» показывается лишь когда элемент есть с обеих сторон. Выбор корректно перекладывается в файл настроек Конфигуратора (DoNotMerge / GetFromSecondConfiguration).
Единая рекомендация в дереве и окне кода
Дерево сверки и окно кода считали рекомендацию от разных фактов (категория против наличия тел) и могли показывать разные режимы для одной функции. Теперь наличие сторон приходит из карты сравнения и обе точки совпадают; окно кода различает «функция отсутствует в версии» и «функция есть, но тело не извлечено из поставки». Кэш окна кода привязан к сравниваемым версиям — после пересравнения или перезагрузки поставки старые тела больше не показываются. Плашка «из поставки» ставится только функциям, которых действительно нет в вашей конфигурации.
Пакет обновления расширения (без новой вендорской .cfe)
Принятые предложения перехватов копятся кнопкой «В пакет расширения»; кнопка «Обновление расширения» на панели версий по вашей текущей .cfe (выгружается из базы штатно) собирает zip: ext-merge.xml — настройка объединения, включающая НОВЫЕ тексты затронутых модулей, — и пакет .bsl для ручной доработки. Дальше — штатное «Сравнение, объединение» расширения с этой .cfe в Конфигураторе. Контейнер Analyzer не пишет — только читает.
Обновление перехватов расширений по итогу объединения
В окне кода результат объединения и переопределения из расширений стоят рядом двумя равными панелями с синхронной прокруткой; в перехвате подсвечены зоны отличий от текущего результата. Для подменяющих перехватов (&Вместо без ПродолжитьВызов, &ИзменениеИКонтроль) кнопка «Предложить обновление перехвата» строит обновлённый вариант трёхсторонним объединением по старой типовой: правки вендора применяются автоматически, правки расширения сохраняются, пересечения помечаются блоком «// Новый код вендора». В предложении зелёным подсвечены изменённые относительно исходного перехвата строки; итог редактируется и выгружается файлом .bsl (или копируется) для переноса в расширение.
Перехваты расширений видны в дереве сверки
Конфликтная пометка «V14; перехват» больше не теряется у функций, которых не было в базовой поставке (реальный случай: &ИзменениеИКонтроль показывался в окне кода, но не в дереве). Неподменяющие перехваты (&Перед/&После, &Вместо с ПродолжитьВызов) теперь тоже видны в дереве нейтральной плашкой 🔌 с именем расширения — раньше о них знало только окно кода.
Индексирование реквизитов авто-объектов читается из поставок вендора
У автоматически создаваемых объектов (*ПрисоединенныеФайлы и подобных) в поставках, собранных вендором, флаг индексирования хранится в особой раскладке и терялся — сотни ложных «индексирование: да → нет» при сверке. Теперь читается честно (сверено с эталоном: 12133 из 12134 совпадений). Для уже загруженных поставок — перерегистрируйте их, чтобы пересчитались отпечатки.
Фильтр «Только перехваченные»
В окне «Фильтр» дерева сверки появился режим работы по перехватам: остаются только функции, которые трогают расширения («V14; перехват» и «🔌»); состояние фильтра видно прямо на кнопке.
Обновление расширения — целиком из разобранных данных, без файлов
Пакет обновления расширения больше не требует никаких .cfe: модули функций берутся из уже разобранной системы, zip содержит настройку объединения с новыми текстами принятых перехватов по модулям и файлы bsl/<Модуль>.<Функция>.bsl для переноса. Расширение объединяется «с самим собой» в Конфигураторе, тексты — из пакета; функции-тёзки в нескольких модулях помечаются в README.
Панель фильтров дерева наведена в порядок
Категории изменений («Конфликт», «Обновится само»…) и «Все типы метаданных» собраны в одну кнопку «Фильтр» (со счётчиком скрытых); «Только неподтверждённые» и счётчик d04; остались на виду. «Выгрузить/Сбросить настройки объединения» объединены в кнопку-меню «Настройки объединения» и перенесены вниз окна — это завершение работы, а не фильтр.
Колонки кода получили визуальную рамку
Верхние окна сравнения (Прошлая поставка · Новая поставка · Текущая конфигурация) обведены рамкой, как нижние панели, — границы окон читаются.
Кнопки панели перехвата не выталкивают навигацию за экран
В режиме предложения перехвата строка действий («Скачать .bsl», «Скопировать», «В пакет расширения»…) переносится на следующую строку — счётчик и стрелки перехода по изменениям всегда видны.
Смена составного типа реквизита читается по клику
Для реквизитов с типом из десятков ссылок (через «|») подсказка не вмещала описание — по клику на «тип: …» открывается раскладка: что добавилось, что ушло, что без изменений (списки с прокруткой).
Кнопки панели версий выстроены по значимости
«Сравнить выделенные» — главная (синяя), ввод данных («Добавить поставку», «Зафиксировать версию») — обычные, «Обновление расширения» — пунктирная, «Лог поставки» — приглушённая текстовая; кнопки больше не заезжают под «Как пользоваться».
Удалённая поставщиком функция: рекомендация учитывает судьбу вызывающих
Если вызывающие удаляемой функции сами обновляются из поставки, где вызова уже нет (сверяются поставочные тела), либо тоже удаляются — окно кода рекомендует «Удалить (как в поставке)» вместо «Сохранить»: сохранение оставило бы мёртвый код. Плашка вызывающих различает «вызов остаётся», «обновится и перестанет вызывать» и «тоже удаляется».
Агрегатный выбор режима и «Подтвердить» на модулях без изменений состава
У элемента, где изменились только функции (типично — общий модуль), вернулись выбор режима и «Подтвердить» на всю ветку разом; решение ставится на функции, лишнее правило на неизменённый объект в выгрузку не пишется.
Большие группы дерева раскрываются без подвисания
Группа типа с сотнями объектов (например «Общие модули (1730)») монтируется порциями по 300 с кнопкой «Показать ещё» — раскрытие/сворачивание больше не замирает.
Кнопка «Остановить» у идущего сравнения
Окно хода сравнения версий и обновления поставки получило кнопку «Остановить»: сравнение прерывается на ближайшем шаге, выбранные версии остаются — можно запустить заново.
Расширен класс «только представление»
Разные версии служебных адресов платформы и запись строк через пространство конфигурации (стиль писателя платформы) больше не считаются вашими правками содержимого макетов.
Если все изменения состава — «Взять из поставки», объект рекомендуется так же
Объект (и конфликтный, и «моё сохранится»), у которого каждое изменение состава рекомендовано «Взять из поставки» (менял только поставщик, «обе стороны» с решением по умолчанию, «только представление»), рекомендуется «Взять из поставки» целиком — рекомендация контейнера совпадает с содержимым и так же ложится в выгрузку настроек объединения. Страховка: если в объекте есть ваши правки функций, рекомендация контейнера не меняется — иначе правило объекта затёрло бы модули с вашим кодом.
Полный текст деталей подчинённого — во всплывающей подсказке строки
Длинные детали («тип: … → …», «индексирование: …», переименование) усекались по ширине, и прочитать их было негде — теперь подсказка строки реквизита/формы/макета содержит полный текст построчно.
«Только неподтверждённые» скрывает и подтверждённые подчинённые
Подтверждённые (d04;) реквизиты/формы/макеты уходят из видимости сразу, а не после подтверждения всего объекта — как это уже работало для функций.
Перехват больше не помечает функцию-тёзку в другом модуле объекта
Перехват из объектного модуля расширения помечал и уводил в конфликт одноимённую функцию менеджерского модуля того же объекта (и наоборот), которую никто не перехватывал, — при этом окно кода честно показывало, что перехвата нет. Теперь пометка «V14; перехват»/«🔌» и конфликт по перехвату ставятся только функции того же модуля (и той же формы), что и перехватчик.
Скроллы нижних панелей окна кода не пропадают
Полосы прокрутки редактора «Результат объединения» и панели перехвата (в том числе после «Предложить обновление перехвата») выступали за рамку и срезались — прокрутка выглядела пропавшей.
Навигация по изменениям в панелях перехвата и окне содержимого форм/макетов
У панели «Переопределения в расширениях» и у окна «Сравнить» содержимого форм/макетов появились счётчик изменений и кнопки «предыдущее/следующее» — как в верхних колонках кода: в исходном перехвате — по отличиям от результата объединения, в предложении — по подсвеченным правкам, в окне содержимого — по блокам отличий версий (колонки прокручиваются синхронно; трёхколоночный режим выровнен построчно, как окно функций).
Отличия «только представление» авторекомендуются «Взять из поставки»
Изменённые формы/макеты, у которых содержимое совпадает по сути и различается только внутренним представлением (тип записан кодом либо именем, явные и опущенные значения по умолчанию, пространства имён), помечаются «≈ представление» и сразу рекомендуются к взятию из поставки: приняв вариант поставщика, вы выравниваете представление своей конфигурации с ним, и последующие сверки — и в Analyzer, и в «Сравнении, объединении» Конфигуратора — идут чисто.
Ложные «изменения» СКД и форм из-за представления пространств имён устранены
Одинаковое содержимое, сохранённое разными сериализаторами 1С (префикс v8: в конфигурации против d5p1: в поставке, объявление на разных узлах), больше не считается изменением: перед вычислением отпечатка префиксы приводятся к каноническим, объявления не учитываются. Окно сравнения содержимого тоже показывает канонизированный текст — служебный шум префиксов не топит реальные правки. Уже сохранённые версии и поставки пересчитываются миграцией по сохранённым текстам — без перерегистрации.
Трёхстороннее окно сравнения содержимого форм и макетов
В окне «Сравнить» у подчинённых при обновлении поставки появилась третья колонка «Прошлая поставка»: видно, кто менял содержимое — вы или поставщик, как в окне кода функций.
Рекомендации подчинённых учитывают, кто менял элемент
У реквизитов/форм/макетов в обновлении поставки рекомендация выводится из сравнения с прошлой поставкой. Изменённые: «менял только поставщик» → «Взять из поставки», «меняли только вы» → «Сохранить основное», «обе стороны» → пометка «b88; обе стороны» и решение вручную. Удалённые из поставки: «поставщик выпилил, вы не трогали» → «Удалить (как в поставке)», «элемент ваш» → «Сохранить», «вы меняли, а поставщик удалил» → «b88;» и решение вручную. Новые в поставке: «вы удалили, поставка не меняла» → «Не добавлять». Раньше рекомендации были огульными («Взять из поставки» всем изменённым, «Сохранить» всем удалённым) и противоречили голове объекта. В окне «Сравнить» содержимого добавлена плашка «кто менял»: подсветка в обеих панелях — это один и тот же диф «моё ↔ поставка», а не «менялись обе стороны».
Честные подписи пустых сторон в окне содержимого форм/макетов
У добавленной/удалённой формы пустая сторона подписана «в этой версии отсутствует», а сторона без извлечённого содержимого — «содержимое не извлечено»; предупреждение окна больше не обещает, что содержимое бинарной поставки появится после перезагрузки (описания форм и табличные макеты из .cf не извлекаются — сверяются состав, имена и код модулей; на объединение это не влияет).
Плашки в строках дерева сверки не срезаются при нехватке ширины
Плашки «V14; перехват», «🔌» и «изменена логика» вынесены из усекаемой части строки: раньше при узком окне они молча пропадали вместе с хвостом длинного имени функции, и перехват был виден только в окне кода. Теперь усечению подлежит только имя. Дополнительно перехват помечается прямо на свёрнутой строке элемента, без раскрытия ветки: «V14;» — подменяющий (мешает обновлению вендора), «🔌» — доопределяющий.
Пометка ложного конфликта функций-тёзок
Конфликт, у которого тела всех сторон идентичны (следствие известной коллизии имён, различающихся только подчёркиванием), помечается в окне кода плашкой «ложный конфликт функций-тёзок» с подсказкой закрыть его «Сохранить основное» — вместо загадочного конфликта без видимых отличий. Полное исправление коллизии — отдельным релизом.
Время создания версий — в вашем часовом поясе
Колонка «Создана» в списке версий показывала время сервера (UTC); теперь — локальное время пользователя.
Правило объединения для переименованных объектов — под обоими именами
В файл настроек Конфигуратора правило переименованной пары выгружается и под старым именем (существующим в основной конфигурации), и под новым из поставки — какое имя ни ожидала бы версия Конфигуратора, правило применится.
Предупреждение об устаревшем сравнении
Если версии, с которыми строилось открытое сравнение, были перезагружены или удалены (их ключи изменились), окно кода показывает плашку «Сравнение устарело — выполните сравнение заново» вместо ложного «функция отсутствует у поставщика».
Плашка «≡ эталон» у типовых функций
В анализе функций функции, совпадающие с эталоном поставщика, помечены зелёной плашкой «≡ эталон» (доработанные — «c98; доработана», как раньше).
Переход по изменениям в окне сравнения кода
Компактные кнопки-стрелки ↑/↓ со счётчиком прыгают по блокам изменённых строк; все колонки прокручиваются синхронно — как «Следующее различие» в Конфигураторе.
Правильные рекомендации для реквизитов и состава объекта
Реквизит, добавленный или изменённый новой поставкой, получает рекомендацию «Взять из поставки» (раньше — ошибочное «Сохранить основное»); в выборе режима видна причина рекомендации. Рекомендации реквизитов согласованы с объектом: если объект менял только вы («моё сохранится»), его реквизиты тоже рекомендуются «Сохранить основное», а не противоречащее «Взять из поставки»; если менял только поставщик — «Взять из поставки».
Каскад решения и подтверждения с объекта
Режим объединения и кнопка «Подтвердить», выбранные на строке объекта, применяются ко всем функциям и реквизитам под ним; снятие подтверждения снимает его со всего поддерева.
Переименования «Удалить…» распознаются
Пара «удалён реквизит X / добавлен УдалитьX» показывается одной строкой «переименование: X → УдалитьX» — стандартная практика обновления 1С больше не выглядит как два отдельных изменения. То же для ОБЪЕКТОВ верхнего уровня: справочник, переименованный вендором в «Удалить…» (например ГосударственныеКонтракты → УдалитьГосударственныеКонтракты), — одна строка переименования, а не пара «добавлен/удалён».
Объекты сверяются по GUID (основа), имя — фолбэк
Матчинг объектов при сверке версий теперь ведётся по GUID из метаданных: переименованный вендором объект (любое новое имя, не только «Удалить…») распознаётся как ОДИН объект со строкой «переименование: X → Y». GUID приходит из XML/EDT-выгрузки и из бинарной поставки; у данных, загруженных до этой версии, GUID нет — там работает прежний матч по имени и эвристика «Удалить…». Эффект — после перезагрузки конфигурации и перерегистрации поставок.
GUID'ы реквизитов, табличных частей, форм и макетов
Сверка состава объекта тоже ведётся по GUID: переименованный реквизит (включая перенос между табличными частями), форма или макет матчится как один элемент со строкой «переименование: X → Y», а не парой «добавлен/удалён»; без GUID — прежний матч по имени и «Удалить…». GUID'ы приходят из ОБОИХ форматов: XML/EDT-выгрузки и бинарной поставки (реквизиты и ТЧ — из шапок членов, формы и макеты — из собственных GUID'ов в контейнере).
GUID'ы у всех видов метаданных
GUID теперь извлекается и сверяется у ВСЕХ видов, участвующих в сверке версий: ролей, подсистем, подписок на события, функциональных опций, регламентных заданий, команд, HTTP- и Web-сервисов, XDTO-пакетов, определяемых типов, планов видов характеристик, параметров сеанса, критериев отбора. Переименованная вендором сущность любого вида распознаётся как одна строка «переименование: X → Y», а не пара «добавлена/удалена». Данные без GUID (старые загрузки) сверяются по имени, как раньше.
Полные списки форм и макетов у бинарной поставки
Раньше бинарная поставка несла только формы и макеты с извлечённым содержимым (на ЗУП — 642 формы из 4010), поэтому добавления и удаления форм/макетов при сравнении с .cf вовсе не показывались. Теперь поставка отдаёт ПОЛНЫЙ список форм и макетов (имя + GUID; содержимое — где извлеклось): добавленные, удалённые и переименованные формы и макеты видны честно; сравнение содержимого остаётся только для извлечённых.
Изменения состава переименованного объекта не теряются
Для склеенной пары переименования (по GUID или «Удалить…») теперь считается дельта состава между старым и новым объектом: изменённые реквизиты/формы/макеты видны внутри строки переименования, а не пропадают вместе со схлопнутой парой.
Отпечатки макетов без дублей
Каждый макет в XML-выгрузке давал ДВЕ записи отпечатка (описатель и содержимое под одним именем — на живом ЗУП 3603 дубля) — лишний шум в сигнатуре макетов при сравнении с бинарной поставкой, где запись одна. Теперь отпечаток строится только по содержимому, GUID — по описателю; стороны согласованы. Версии, зафиксированные до исправления, могут один раз показать объекты с макетами «изменёнными».
Убрано ложное «тип изменился» у значений характеристик
При сравнении с бинарной поставкой реквизиты вида «значение характеристики» больше не помечаются изменёнными из-за разного представления одного и того же типа двумя сторонами сравнения.
Сверка форм и макетов с бинарной поставкой
Поставка теперь несёт отпечатки форм и макетов (раньше их не было вовсе — изменения форм и макетов при сравнении с поставкой молча не показывались). Сравниваются формы и макеты, содержимое которых удалось извлечь из бинарного файла; отсутствие остальных в поставке не выдаётся за «удаление». Действует для поставок, загруженных начиная с этой версии.
Полнее читается состав объектов из бинарной поставки
Закрыты остатки недоизвлечения: реквизиты планов видов характеристик и части регистров сведений (52 объекта ЗУП шли с пустым составом — осталось 3 единичных), «любая ссылка» в составных типах и представление «объект/ссылка» больше не дают ложного «тип изменился» (из 14 ложных строк типов осталась 1 спорная). Сравнение с версиями, зафиксированными до этого обновления, может один раз подсветить такие объекты изменёнными — перефиксируйте версию или перезагрузите поставку.
Индексирование реквизитов читается из бинарной поставки для всех видов
Раньше у регистров сведений, бизнес-процессов, задач и присоединённых файлов флаг индексирования из бинарного файла не извлекался, и сверка показывала ложное «индексирование: да → нет» (на ЗУП — 236 ложных строк, после исправления осталось 6 спорных). Настоящие отличия индексов по-прежнему показываются.
Предопределённые элементы читаются из бинарной поставки
Списки предопределённых (справочники, планы видов характеристик и др.) теперь извлекаются из бинарного файла — их изменения видны в сверке состава, а у систем, загруженных из бинарного файла, предопределённые появляются в графе. Проверено на ЗУП: 81 объект совпал с эталонной выгрузкой слово в слово, у 3 списки отличаются ровно на элементы более новой версии (сверка шла с поставкой постарше), расхождений нет; вне сверки — только объекты расширений, которых в файле поставщика и не бывает.
Перезагрузка систем: не требуется.
Изменения
Пользователи и разграничение доступа (роли)
Появился вход по логину и паролю с ролями «Администратор», «Тимлид» и «Наблюдатель»: администратор заводит пользователей, назначает роли и — при необходимости — ограничивает каждому список доступных систем. Раздел «Пользователи и доступ» с журналом действий и настраиваемой длительностью сессии. По умолчанию разграничение выключено — поведение «из коробки» прежнее, вход не требуется; включается администратором стенда.
Вход через корпоративный каталог: LDAP / Active Directory и OpenID Connect
Пользователи могут входить учётной записью домена (LDAP / Active Directory) или через единый вход организации (OpenID Connect — ADFS, Keycloak и совместимые). Роль выдаётся автоматически по группе пользователя в каталоге; правила сопоставления «группа → роль» задаёт администратор.
Персональный токен доступа для встроенного окна в 1C:EDT
При включённом разграничении доступа встроенное окно Analyzer в 1C:EDT (плагин Effector 1C) входит по персональному токену — работает под вашей ролью и вашим списком систем. Если конфигурация из EDT не загружена на сервере, окно показывает понятную плашку вместо ошибки.
Вкладка «Запросы» открыта всем объектам, читаемым запросами
Разбивка читателей и писателей по запросам (кто читает объект в отчётах, СКД и формах) теперь доступна в карточке любого объекта, который язык запросов принимает как таблицу: справочники, документы, перечисления, константы, планы видов характеристик, счетов и расчёта, планы обмена, задачи, бизнес-процессы, последовательности. Раньше вкладка показывалась только у регистров и журналов документов, хотя руководство обещало её шире.
Перезагрузка систем: не требуется.
Изменения
Создание системы из git: распознаются репозитории с вложенной папкой
Загрузка конфигурации из git-репозитория, где проект лежит не в корне, а во вложенной папке (типовая выгрузка 1C:EDT с папкой-обёрткой), больше не попадает в «нераспознанное» — система создаётся и загружается штатно.
Перезагрузка систем: ТРЕБУЕТСЯ — для пересчёта иерархии подсистем, полных прав ролей и графа вызовов (динамические вызовы общих модулей).
Изменения
Эталоны поставщиков: фильтр «покажи только наши доработки»
Зарегистрированную поставку (.cf/.cfe, можно несколько от разных вендоров) можно пометить «Эталоном» в «Версиях» — каждая функция получает пометку «типовая» (совпадает с поставкой), «доработана» или «вне эталонов». В «Циклах» вендорские кольца скрываются по умолчанию, в «Анализе функций» — флажок «Скрыть типовые», доработки помечены «c98;», в детали функции виден источник. Пометки пересчитываются автоматически после каждой перезагрузки системы.
Сверка и объединение версий на уровне Конфигуратора 1С
Выравнивание строк кода (2- и 3-стороннее), окно модуля со всеми функциями и живым предпросмотром результата объединения, ручная валидация решений («Подтверждено») и выгрузка только подтверждённых настроек, блоки «// Было» / «// Новый код вендора» при объединении, сверка содержимого форм и макетов, детали изменений реквизитов и предопределённых элементов, группировка правок по формам и модулям.
Права ролей приведены к Конфигуратору
Роли «с правами по умолчанию» («Полные права») материализуются полным набором применимых прав, включая неосновные (история данных, управление итогами); блок «Снятые права (исключения)»; подписи всех прав — дословно как в окне «Права» Конфигуратора.
Правильная иерархия подсистем
Одноимённые подсистемы в разных ветках больше не схлопываются: в ЗУП КОРП возвращены 85 терявшихся подсистем, дочерние подсистемы отображаются правильно.
Устойчивость загрузки
Сбой одной системы при массовой загрузке не останавливает остальные (сводка «успешно X/Y» + подсветка сбоя в интерфейсе); гибель пула BSL-разбора доживается последовательным добором без потери модулей; разбор модуля при единичном сбое повторяется — функции больше не теряются тихо; устранены обрывы на больших формах.
Точнее кандидаты на удаление
Вызовы через ОбщегоНазначения.ОбщийМодуль("Имя") попадают в граф вызовов.
Единое поле поиска
Весь поиск в левой панели — через одно верхнее поле (конструктор профилей, функциональные опции, определяемые типы, планы ВХ, параметры сеанса, критерии отбора, обновление ИБ, XDTO-пакеты, MCP-инструменты, изучение подсистем); результаты поиска не «отстают» от набранного запроса, одноимённые команды различаются символьным именем.
Быстрый итоговый набор прав в конструкторе профилей
Считается за доли секунды и для «полных» ролей (было ~15 секунд); принадлежность роли к подсистемам подписана «справочно, не права».
Журнал изменений в дистрибутиве
В каждом архиве теперь лежит changelog.txt — значимые изменения по прод-версиям, с пометкой, нужна ли перезагрузка систем после обновления.
Удобство интерфейса
Закреплённые панель отборов и шапка таблицы в «Анализе функций», значок вклада расширения на верхних уровнях состава функциональной опции, переход к тексту функции из блока «Проверяется в коде», список «Изучение подсистем» по алфавиту, бодрее масштабирование графов колёсиком.
Перезагрузка систем: не требуется (относительно 2.1.18).
Изменения
Исправлены ошибки 500 в сборке 2.1.18
Часть запросов интерфейса (в том числе журнал загрузки) отвечала ошибкой 500.
Перезагрузка систем: ТРЕБУЕТСЯ — состав и тип возврата функций вычисляются при загрузке.
Изменения
Возвращаемое значение функций
Состав Структур/Таблиц значений, тип и константное значение возврата для 100% функций — в панели детали функции (секция «Возвращаемое значение» с источником каждого поля: тело / комментарий / расширение) и в MCP-инструменте get_function. Точность выверена сплошными аудитами ЗУП и ЕРПУХ.
Интерфейсные обёртки
Распознавание функций-обёрток над регистрами и делегатов; тип протягивается по цепочке вызовов.
Удобство «Анализа функций»
Поиск по имени функции, колонка «Модуль» (менеджер/объект/форма/команда), у методов форм видна форма-источник; «Показать функцию» работает для функций форм (до этого ~40% функций были без просмотра).
Прогресс загрузки
Единый прогресс со скоростью и ETA у всех этапов, тайминги фаз в логе; устранены падения на крупных монорепо и на модулях с незакрытым литералом.
Перезагрузка систем: ТРЕБУЕТСЯ (первичная установка/обновление со сменой мажорной версии — загрузить конфигурации заново).
Изменения
Первая прод-сборка мажорной версии 2.0.
Сверка версий конфигураций (мажорная фича 2.0)
Фиксация версий системы, загрузка вендорских поставок (.cf/.cfe), двух- и трёхстороннее сравнение (Основная/Поставщик/База) с деревом «как в Конфигураторе», рекомендации решений и выгрузка настроек объединения (.xml/.zip) для Конфигуратора.
MCP-сервер над графом конфигурации + панель «MCP-инструменты»
Поиск объектов и функций (морфология, ранжирование по смыслу), структура объекта, движения документов — для ИИ-агентов.
Бинарные .cf/.cfe
Прямая загрузка контейнеров без выгрузки в XML, включая состав реквизитов/ТЧ/индексирование (объектное совпадение с XML-выгрузкой 92%+) и гигантские конфигурации (потоковое чтение).
Интеграция с EDT
«Показать/Открыть функцию в EDT», встроенный режим внутри EDT с историей переходов.
Граф вызовов
Маркеры клиент-серверных переходов на рёбрах.
Подчинённость справочников
Владелец (подчинённость) в графе и MCP.
Технические требования
Работоспособность гарантируется:
-
Программа не задействует Платформу 1С.
-
Тестировалась выгрузка на 8.3.27.1719,
-
Будет одинаково работать с любой платформой 1С, где реализована выгрузка данных конфигурации в файлы. Также поддерживается формат 1С:EDT (файлы
.mdo/.rights) напрямую, без промежуточной выгрузки в XML.На слайдах 1С:ERP. Управление холдингом (3.2.8.11)
Код открыт.
Остались вопросы?
Для получения дополнительной информации и помощи в настройке модуля под нужды вашего бизнеса — оставьте заявку
