При обновлении конфигураций в 1С 8.3, особенно если мы работаем с измененной конфигурацией, находящейся на поддержке, часто возникает ситуация, когда поведение системы кажется нелогичным. Одно из таких поведений — это различное состояние флажков участия в объединении в окне "Сравнение и объединение конфигураций" при использовании фильтра "Показывать только дважды измененные свойства". Давайте вместе разберемся, почему так происходит, и что на самом деле стоит за этим сложным механизмом.
Наш коллега, обновляя конфигурацию Бух КОРП, столкнулся именно с такой проблемой. После загрузки файла обновления (CFU) и открытия окна сравнения, он выбрал фильтр, чтобы видеть только те свойства, которые были изменены как поставщиком, так и им самим. Однако, флажки участия в объединении, которые показывают, будет ли объект обновлен из конфигурации поставщика, оказались установлены по-разному:
Такое поведение вызывает закономерные вопросы и может привести к ошибкам, если мы не понимаем его логику. Мы выясним, почему система ведет себя именно так.
Прежде чем углубляться в детали поведения флажков, давайте уточним, что означает фильтр "Показывать только дважды измененные свойства". Этот фильтр является одним из самых важных при обновлении доработанных конфигураций. Его основная задача — выделить те элементы конфигурации, которые требуют нашего ручного внимания.
Когда мы говорим о "дважды измененных" свойствах, мы имеем в виду, что платформа 1С обнаружила изменения в одном и том же свойстве или объекте конфигурации одновременно в двух "местах":
Таким образом, "дважды измененные свойства" — это точки конфликта, где и мы, и поставщик внесли изменения. В большинстве других случаев (например, если объект изменен только нами, или только поставщиком, или не изменен вообще) система может автоматически определить правила объединения. Но при двойном изменении требуется наше участие, чтобы решить, как именно объединить эти изменения. Именно поэтому эти объекты всегда отображаются при данном фильтре, но состояние флажка по умолчанию может варьироваться.
Теперь мы можем приступить к анализу основных причин, по которым флажки участия в объединении устанавливаются по-разному, даже для "дважды измененных" объектов. Это результат сложной логики работы механизма сравнения и объединения платформы 1С.
В конфигурации пользователя существуют три основных правила поддержки, которые определяются разработчиком типового решения и могут быть дополнительно настроены нами:
При сравнении конфигураций может возникнуть до десяти различных ситуаций, и девять из них система разрешает однозначно. Однако, в случае, когда объект изменен в обеих конфигурациях (т.е. является "дважды измененным"), и при этом он снят с поддержки, по умолчанию будет применено правило "Взять из конфигурации пользователя". Это означает, что изменения поставщика по умолчанию не будут учтены, и, следовательно, флажок участия в объединении будет снят. Мы должны помнить об этом нюансе, так как он напрямую объясняет, почему у некоторых объектов, даже если они "дважды изменены", флажок может быть снят по умолчанию, если они были ранее явно или неявно сняты с поддержки.
Платформа 1С обладает полезной функцией запоминания наших решений. Правила, которые мы задавали вручную при предыдущих обновлениях для объектов конфигурации, находящейся на поддержке с возможностью изменения, сохраняются.
Что это значит для нас? Если при одном из прошлых обновлений мы вручную сняли или установили флажки для определенных объектов, эти настройки будут автоматически применены при следующем обновлении. Таким образом, если нам кажется, что флажок установлен "странно", возможно, это не "глюк" системы, а результат наших собственных действий в прошлом. Это помогает автоматизировать процесс, но требует от нас помнить о принятых ранее решениях.
Мы видели, что флажок может быть установлен на верхнем уровне иерархии объекта (например, для общего модуля), но при этом снят для вложенных объектов (например, для конкретных процедур или функций внутри этого модуля). Почему так происходит?
Это может быть связано с тем, что система находит различия на уровне свойств самого объекта (например, изменился признак "Экспорт" у общего модуля, или его комментарий), но при этом не видит пересекающихся изменений во вложенных элементах (например, в тексте процедур или функций), которые требуют ручного объединения. Допустим, поставщик добавил новую процедуру в модуль, а мы изменили текст другой процедуры в этом же модуле. В этом случае система может показать, что модуль изменился (потому что добавлена новая процедура), но внутри этого модуля для существующих процедур, если наши и поставщика изменения не накладываются друг на друга в одних и тех же строках, флажки могут быть сняты, так как явного конфликта на уровне кода не обнаружено.
Для некоторых объектов конфигурации или их реквизитов, особенно примитивных типов (например, число, строка, дата), режим объединения может отсутствовать в принципе. Для них возможен только режим замещения ("Взять из загружаемой конфигурации") или сохранения ("Взять из конфигурации пользователя"). В таких случаях флажок участия в объединении просто не будет отображаться, так как нет возможности выбора сложной стратегии слияния.
Кроме того, если для объекта установлено правило поставщика, запрещающее его изменение (мы увидим это по пиктограмме в виде замкнутого замка), такой объект можно только просмотреть. Объединять или изменять его непосредственно через окно сравнения невозможно, и соответственно, флажок у него также будет отсутствовать.
При обновлении конфигурации, находящейся на поддержке, процесс сравнения не ограничивается только нашей текущей конфигурацией и новой конфигурацией поставщика. В процессе также участвует старая конфигурация поставщика, которая хранится в информационной базе.
Для чего это нужно? Старая конфигурация поставщика служит точкой отсчета. Она позволяет системе анализировать изменения относительно трех версий:
Такой "трехсторонний" анализ дает возможность более точно определить, какие свойства были "дважды изменены", то есть, где изменения есть как со стороны пользователя (относительно старой типовой), так и со стороны поставщика (в новой типовой). Это сложный алгоритм, который помогает избежать ложных срабатываний и более корректно представить конфликты.
Как мы уже кратко упомянули, "дважды измененные свойства" — это ситуации, когда основная конфигурация (пользователя), старая конфигурация поставщика и новая конфигурация поставщика отличаются между собой по одному и тому же свойству или объекту. То есть, изменения есть как со стороны пользователя относительно старой типовой, так и со стороны поставщика в новой типовой.
Например, если в старой типовой конфигурации был код Сообщить("Привет");, мы изменили его на Сообщить("Привет, мир!");, а поставщик в новой типовой конфигурации изменил тот же код на Сообщить("Привет всем!"); — это типичный случай "дважды измененного свойства", требующий нашего вмешательства. Однако, в зависимости от контекста, правил поддержки и истории обновлений, начальное состояние флажка для такого объекта может варьироваться.
Хотя наш коллега сомневался, что речь идет о "глюках" платформы, стоит признать, что иногда в работе механизма сравнения и объединения 1С могут встречаться особенности поведения. Например, бывают случаи, когда в "дважды измененные" объекты попадают те, в которые мы фактически не вносили никаких изменений.
Причины таких аномалий могут быть разнообразными: это могут быть особенности внутренней работы платформы, влияние различных используемых библиотек (например, WebKit для работы с HTML-полями), или даже различия в невидимых символах или форматированных строках, которые система воспринимает как изменения, приводя к ложным срабатываниям механизма сравнения. В таких редких случаях, даже если нам кажется, что изменений нет, платформа может все равно показать объект как "дважды измененный", и нам придется вручную убедиться в отсутствии конфликтов.
Мы видим, что различное состояние флажков при использовании фильтра "Показывать только дважды измененные свойства" — это не случайность, а следствие комплексного анализа изменений платформой 1С 8.3. Этот анализ учитывает правила поддержки, историю предыдущих обновлений, иерархию объектов, их индивидуальные особенности и даже особенности внутреннего представления данных.
Итак, что же нам делать, сталкиваясь с таким поведением?
Внимательный анализ каждого объекта: Мы не должны полагаться только на автоматическую расстановку флажков. Как поступал наш коллега, методично просматривайте каждый "дважды измененный" объект. Это единственный надежный способ убедиться, что все изменения учтены корректно. Откройте для сравнения модули, формы, макеты и другие объекты, чтобы визуально оценить характер изменений.
Понимание логики изменения: Перед принятием решения постарайтесь понять, что изменил поставщик и что изменили мы. Для этого используйте встроенные возможности сравнения текста модулей, форм или других объектов. Платформа 1С предоставляет удобные инструменты для выделения различий.
Выбор стратегии объединения: Основываясь на анализе, мы выбираем одну из стратегий:
"Взять из конфигурации поставщика" (установить флажок): Мы устанавливаем флажок, если изменения поставщика приоритетны, наши изменения некритичны или легко переносятся в обновленный типовой код. После объединения нам придется вручную перенести свои доработки в новую версию объекта. Это часто предпочтительный подход, так как позволяет максимально сохранить типовой функционал.
// Пример: был наш код
// Процедура НашаДоработка()
// Сообщить("Наша уникальная функция");
// КонецПроцедуры
// После установки флажка и объединения, если поставщик изменил этот модуль,
// наш код может исчезнуть, и нам придется его снова вставить.
"Взять из конфигурации пользователя" (снять флажок): Мы снимаем флажок, если наши пользовательские изменения имеют высокий приоритет и конфликтуют с типовыми, или поставщик внес минимальные изменения, которые легко интегрировать вручную в нашу версию. В этом случае изменения поставщика не будут применены автоматически, и нам придется вручную перенести нужные изменения поставщика в нашу доработанную версию.
// Пример: поставщик добавил новую функцию:
// Процедура НовыйФункционалПоставщика()
// // ...
// КонецПроцедуры
// Если мы снимем флажок, эта функция не будет добавлена автоматически.
// Нам придется вручную скопировать ее из конфигурации поставщика в нашу.
Использование режима "Объединить": Для текстовых модулей, макетов и форм часто доступен режим "Объединить", который позволяет построчно или поблочно выбрать, какие изменения оставить из нашей конфигурации, а какие — из конфигурации поставщика. Это самый детализированный и точный способ слияния кода.
Запоминание решений: Помните, что платформа запоминает ваши решения. Это означает, что если вы тщательно проработаете текущее обновление, многие из принятых решений будут автоматически применены в следующих циклах обновления, что значительно облегчит работу в будущем. Это делает наши усилия по ручному анализу не напрасными.
В заключение, различное состояние флажков участия в объединении в 1С 8.3 не является ошибкой или случайностью. Это проявление сложного, многофакторного алгоритма, разработанного для того, чтобы помочь нам максимально гибко управлять изменениями в модифицированных конфигурациях. Понимание этих причин помогает нам принимать осознанные решения при каждом обновлении, минимизировать риски потери данных или функционала и эффективно поддерживать наши информационные системы на базе 1С.