Ошибки обратного импорта через проект IB-->XML-->EDT-->XML-->IB при отсутствии ошибок IB-->XML-->IB

Описание ошибки

Если взять абсолютно типовую конфигурацию (УХ 3.2.7.11) сконвертировать её XML, потом в проект EDT, то при обратной последовательности при сборке из XML возникают ошибки.

Как воспроизвести

Ниже воспроизведём сначала безошибочную последовательность: 1. Создаём базу из конфигурационного файла C:\Users\USER>"c:\Program Files\1cv8\8.3.23.1997\bin\ibcmd.exe" infobase create --db-name=w:\trash\UHT --load=d:\tmplts\1c\CorporatePerformanceManagement\3_2_7_11\1cv8.cf --data=w:\trash\UHT_DATA [INFO] Создание информационной базы... [INFO] Создание информационной базы успешно завершено [INFO] Загрузка конфигурации... [INFO] Загрузка конфигурации успешно завершена

2. Выгружаем в XML C:\Users\USER>"c:\Program Files\1cv8\8.3.23.1997\bin\ibcmd.exe" config export w:\trash\UHT_XML --db-name=w:\trash\UHT --data=w:\trash\UHT_DATA [INFO] Экспорт конфигурации в XML... [INFO] Экспорт конфигурации в XML успешно завершен

3. Загружаем обратно в другую, новую базу C:\Users\USER>"c:\Program Files\1cv8\8.3.23.1997\bin\ibcmd.exe" infobase create --db-path=w:\trash\UHT1 --import=w:\trash\UHT_XML --data=w:\trash\UHT_DATA [INFO] Создание информационной базы... [INFO] Создание информационной базы успешно завершено [INFO] Импорт конфигурации из XML... [WARN] Файл - w:/trash/UHT_XML/DataProcessors/ОнлайнСервисыРегламентированнойОтчетности/Templates/УведомлениеОБлокировкеОбъекта/Ext/Template/ru.html: Возможно неверная ссылка ПутьККартинке внутри справки. [WARN] Файл - w:/trash/UHT_XML/DataProcessors/ОнлайнСервисыРегламентированнойОтчетности/Templates/УведомлениеОБлокировкеФормыИЛИФормата/Ext/Template/ru.html: Возможно неверная ссылка ПутьККартинке внутри справки. [INFO] Импорт конфигурации из XML успешно завершен

Далее, повторим длинную цепочку: 4. Импортируем проект из XML с шага 2 C:\Users\USER>ring edt workspace import --project w:\trash\UHT_p --workspace-location w:\trash\UHT_ws --configuration-files w:\trash\UHT_XML Debug options: file:/C:/Users/USER/AppData/Local/1C/1cedtstart/installations/1CEDT (Lite) 2023.2/1cedt/.options loaded SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: com._1c.g5.v8.dt.internal.core.lifecycle.DtProjectResourceLifecycleBootstrap$ResourceActivityCompletionWatchdogJob Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: org.eclipse.core.internal.refresh.RefreshJob Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: com._1c.g5.v8.dt.internal.core.lifecycle.ServiceProviderActivationListener$DefaultContextInitializationJob Job found still running after platform shutdown. Jobs should be canceled by the plugin that scheduled them during shutdown: org.eclipse.core.internal.events.NotificationManager$NotifyJob Проект успешно импортирован из файлов конфигурации платформы 1С:Предприятия.

5. Экспортируем проект в XML в новый каталог XML2 C:\Users\USER>ring edt workspace export --project w:\trash\UHT_p --workspace-location w:\trash\UHT_ws --configuration-files w:\trash\UHT_XML2 Debug options: file:/C:/Users/USER/AppData/Local/1C/1cedtstart/installations/1CEDT (Lite) 2023.2/1cedt/.options loaded SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.apache.ignite.internal.util.GridUnsafe$2 (file:/C:/Users/USER/AppData/Local/1C/1cedtstart/installations/1CEDT (Lite) 2023.2/1cedt/../../../../../../../.p2/pool/plugins/com._1c.g5.v8.bm.core_8.1.0.v202312202027.jar) to field java.nio.Buffer.address WARNING: Please consider reporting this to the maintainers of org.apache.ignite.internal.util.GridUnsafe$2 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release 0 [derived_data_executor_8] WARN org.eclipse.xtext.conversion.impl.AbstractLexerBasedConverter - Only terminal rules are supported by lexer based converters but got ID which is an instance of ParserRule Проект успешно экспортирован в файлы конфигурации платформы 1С:Предприятия.

6. Импортируем XML2 во вторую базу C:\Users\USER>"c:\Program Files\1cv8\8.3.23.1997\bin\ibcmd.exe" infobase create --db-path=w:\trash\UHT2 --import=w:\trash\UHT_XML2 --data=w:\trash\UHT_DATA [INFO] Создание информационной базы... [INFO] Создание информационной базы успешно завершено [INFO] Импорт конфигурации из XML... [ERROR] Операция невозможна: при выполнении импорта конфигурации из XML обнаружены критичные ошибки [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.Год". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.ОКПД2". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.Процент". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.ПустаяКолонка". [WARN] Файл - w:/trash/UHT_XML2/DataProcessors/ОнлайнСервисыРегламентированнойОтчетности/Templates/УведомлениеОБлокировкеОбъекта/Ext/Template/ru.html: Возможно неверная ссылка ПутьККартинке внутри справки. [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.Организация". [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.УчастиеВМеждународнойГруппеКомпаний". [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.СтрановойОтчет". [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.Организация". [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.СтрановойОтчет". [ERROR] Файл - w:/trash/UHT_XML2/DataProcessors/ПодготовкаМежстрановойОтчетности/Forms/Форма/Ext/Form.xml: Неверный путь к данным: "СписокОрганизаций.УчастиеВМеждународнойГруппеКомпаний". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.НомерКартинкиПодписанЗашифрован". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.Наименование". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.Автор". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.ДатаМодификацииУниверсальная". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.Изменил". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.Ссылка". [ERROR] Файл - w:/trash/UHT_XML2/Catalogs/МероприятиеПрисоединенныеФайлы/Forms/ФормаВыбора/Ext/Form.xml: Неверный путь к данным: "Список.Ссылка". [WARN] Файл - w:/trash/UHT_XML2/DataProcessors/ОнлайнСервисыРегламентированнойОтчетности/Templates/УведомлениеОБлокировкеФормыИЛИФормата/Ext/Template/ru.html: Возможно неверная ссылка ПутьККартинке внутри справки. [ERROR] Импорт конфигурации из XML завершен с ошибкой

Скриншоты

Как я поняла проблема заключается, что в оригинальной XML выгруженной из конфигурации присутствуют тильды перед путём, после конвертации из проекта EDT они уже отсутствуют:

Ожидаемое поведение

При обратном импорте по цепочке IB-->XML-->EDT-->XML-->IB ошибок быть не должно. Конечно же ошибки вызваны некорректными динамическими списками, присутствующими в 3х формах, но на короткой цепочке IB-->XML-->IB ошибки не возникает. Сначала, получив ошибку на конвертации через проект я хотела отправить ошибку разработчикам конфигурации, но выгрузив/загрузив в XML всё же пишу сюда.

Лог рабочей области

log.txt

Версия 1С:EDT

Ruby 2023.2.4

Операционная система

Windows

Установленные плагины

No response

Дополнительная информация

Платформа 8.3.23.1997

Проблемы явно не в том, что убраны ~ тильды. Это начало появляться у меня на платформе 8.3.23.2040 Вообще без EDT выгружаю расширение в XML и убираются ~ тильды И все ок потом без ~ тильд загружается из этих же XML

В моем случае аналогичная проблема что у вас была вызвана потерей при merge записи в config.xml ссылки на справочник. Что вело к тому что динамические списки становились ошибочными

Вообще без EDT выгружаю расширение в XML и убираются ~ тильды

@omankit, я немножко не согласна :) Насколько я поняла ~ как раз как сигнал - принять форму такой какой есть и принятие решения показывать колонки или нет уже будет на runtime. А в тех случаях, когда при выгрузке конфигуратор понимает, что с формой что то не то, то он к путям эти ~ и добавляет. А если путь полученный из запроса корректен и соответствует "путю" в элементе - колонке, то тильда действительно не нужна. Так почему бы не перенять опыт конфигуратора в EDT? Кривой запрос в дин. списке - ну и хорошо, наставили тильд, пусть в runtime форма разбирается можно колонку отобразить или нет. (Правда будут некоторые вопросы с визуализацией форм) С тильдами проблема появилась гораздо раньше ещё на платформе 8.3.17 (или 8.3.16 я её пропустила).

Так почему бы не перенять опыт конфигуратора в EDT?

@JaneGlass73 Добрый день, EDT поддерживает механизм работы с тильдами или, по-другому, с "битыми" путями.

Вот простой пример: Создаем в EDT справочник с реквизитом (Реквизит1) и форму списка справочника. В элементах формы присутствует Реквизит1. Теперь устанавливаем списку свойство "Произвольный запрос", открываем настройку списка и в запросе удаляем строчку "СправочникСправочник1.Реквизит1". Теперь выгружаем конфигурацию в XML и видим в файле Form.xml такие строчки:

            <InputField name="Реквизит1" id="28">
                <DataPath>~Список.Реквизит1</DataPath>

Т.е. та самая тильда. Возможна ситуация, когда конфигуратор не смог получить корректный путь к данным по каким-то причинам. Не исключено, что в результате ошибки. А EDT, если она смогла корректно разрезолвить путь, тильду на экспорте не создает, а выгружает обычный путь. В случае, если конфигуратор ожидает именно тильду, происходит слом при обновлении базы. Хорошо бы понять в чем причина в данном конкретном случае - ошибка платформы или баг в EDT.

На типовых конфигурациях воспроизвести проблему не получилось, к сожалению. Сильно бы помогло в расследовании, если бы вы смогли прислать простой пример, где происходит слом.

Добрый день!

Возможна ситуация, когда конфигуратор не смог получить корректный путь к данным по каким-то причинам. Не исключено, что в результате ошибки. А EDT, если она смогла корректно разрезолвить путь, тильду на экспорте не создает, а выгружает обычный путь.

Видимо именно так и было, но EDT не должен был "отрезолвить" в этих формах, потому что по этим 3м примерам были зарегистрированы ошибки УХ, потому что там действительно три формы кривые:

Обработка.ПодготовкаМежстрановойОтчётности.Форма в запросе динамического списка присутствует выражение ПЕРВЫЕ 1 и не указана основная таблица, в запросе присутствует комментарий, что запрос заменяется динамически. В этом примере даже уйти из поля запроса не удается, так как он некорректный
РегистрСведений.УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения.ФормаСписка в запросе ссылка на таблицу РегистрСведений.ДоляЗакупокТоваровРоссийскогоПроисхождения, а его уже нет. Как EDT тут смог определить пути - непонятно
Справочник.МероприятияПрисоединенныеФайлы.ФормаВыбора в динсписке указана основная таблица МероприятиеПрисоединенныеФайлы, однако в запросе её нет вовсе, а вместо неё присутствует таблица БилетыПрисоединенныеФайлы

На типовых конфигурациях воспроизвести проблему не получилось, к сожалению.

Это очень странно, учитывая что пример я сделала как раз на только что скачанной типовой конфигурации УХ 3.2.7.11, там как раз целых 3 кейса (см. выше), когда EDT, как Вы утверждаете смог "отрезолвить"и выгрузил поэтому без ~, а конфигуратор (в данном случае ibcmd, но это не меняет сути) - нет. Самый первый пункт в порядке воспроизведения это как раз создание из шаблона нужного релиза, который был скачан отсюда: https://releases.1c.ru/version_file?nick=CorporatePerformanceManagement32&ver=3.2.7.11&path=CorporatePerformanceManagement%5c3_2_7_11%5cCPM_3_2_7_11_setup1c.zip В первом пункте создание новой файловой базы из шаблона который у меня хранится в d:\tmplts Вы точно повторили способ воспроизведения по шагам 1,2,4,5,6? 3й шаг можно пропустить (он для примера был приведён, что если не делать импорт/экспорт проекта EDT то всё хорошо получается). Версии EDT, платформы те же какие указала? Ruby 2023.2.4 / 8.3.23.1997?

EDT поддерживает механизм работы с тильдами или, по-другому, с "битыми" путями.

Это прекрасно, т.е. осталось вылечить те ситуации, когда то что для EDT "норм"(хотя не норм должно быть) то для ibcmd "смерть" PS B вы же поняли, надеюсь, что EDT я не открывала. Все манипуляции в командной строке.

@JaneGlass73 Вот смотрите, что получилось в данном конкретном случае с этой конфигурацией.

Если открыть форму списка регистра сведений УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения в конфигураторе, то можно наблюдать следующую картину:

Видно, что есть 4 элемента формы, у которых прописан путь к данным - полям списка. Если открыть запрос у списка, то он корректный, но внутреннее представление списка (построенное) не соответствует запросу. Если снять форму с поддержки, открыть редактор запроса у списка и просто нажать ОК, то список перестроится и станет корректным (появятся 4 потерянных поля):

Если не скорректировать форму, чтобы список соответствовал запросу, то пути выгрузятся с тильдой, т.к. при экспорте в xml из конфигуратора, проверка путей идет на основании внутреннего представления (ошибочного в данном случае).

Список строится на основании данных запроса. Поэтому когда мы импортируем в EDT конфигурацию из xml, то EDT по запросу строит правильный список:

EDT ничего не знает про то, что в конфигураторе внутреннее представление конфигурации находится в неконсистентном состоянии. Да и это было бы странно, если было бы по-другому. Поэтому ошибки ожидаемые. Более того, по ним сразу можно понять, что что-то не так в конфигураторе.

Если бы запрос был некорректным, то поля не появились бы и в EDT, и тогда пути выгрузились бы с тильдами. В данном случае, нужно исправлять типовую конфигурацию. Возможно также, что есть ошибка в самом конфигураторе. Но для начала нужно проверить конфигурацию поставки "Управление холдингом 3.2.7.11" на консистентность.

Еще интересный момент. Если в конфигураторе открыть запрос и, ничего не меняя, нажать клавишу ESC, то будет вот так:

Т.е. валидация прошла и конфигуратор увидел, что есть несоответствие между представлением списка и запросом.

@vadimeg из того, что Вы объяснили, я поняла следующее:

В конфигураторе была ошибка внутреннего представления, которая связана с тем, что разработчики переименовали регистр в УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения, создали новый регистр ДоляЗакупокТоваровРоссийскогоПроисхождения и форму после этого не переоткрывали, что и привело к несоответствию во внутреннем представлении, т.к. видимо во внутреннем представлении используются УИДы ОМД, а запрос остался прежний, но УИДы у нового регистра другие.
EDT оказался "Умнее" и построил поля не в соответствии с внутренним представлением а в соответствии с запросом, т.е. корректно.
Тогда мне непонятно, почему при сборке на эту форму списка ibcmd выругался (конфигуратор на те же XML ругается, я пробовала):

[ERROR] Операция невозможна: при выполнении импорта конфигурации из XML обнаружены критичные ошибки [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.Год". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.ОКПД2". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.Процент". [ERROR] Файл - w:/trash/UHT_XML2/InformationRegisters/УдалитьДоляЗакупокТоваровРоссийскогоПроисхождения/Forms/ФормаСписка/Ext/Form.xml: Неверный путь к данным: "Список.ПустаяКолонка".

И если всё корректно, как Вы описали, тогда не понятно в чём проблема, всё должно было бы нормально загрузиться, но не загрузилось. Это регистр они скорее всего в новом релизе удалят совсем вместе с кривой формой (кстати, я ошиблась в том, что регистра ДоляЗакупокТоваровРоссийскогоПроисхождения нет, они его создали, просто форму не переоткрывали), но там я описала есть 2 кейса и такие формы в типовой УХ периодически ляпают.

Очень хочется не тратить время на исправление таких ситуаций а заниматься нужными вопросами, а то каждое обновление происходит такая беда.

Ок, попробуем привести поведение в EDT для таких случаев к поведению конфигуратора.

Ок, попробуем привести поведение в EDT для таких случаев к поведению конфигуратора.

А можете сделать так чтобы EDT выгружало XML так как это делает конфигуратор? Потому что невозможно параллельно работать в EDT и конфигураторе. EDT Выгружает Xml и меняет теги местами что в git отражается как изменением файлов.

Из-за этого edt В принципе не применима в нормальной работе.

Ок, попробуем привести поведение в EDT для таких случаев к поведению конфигуратора.

А можете сделать так чтобы EDT выгружало XML так как это делает конфигуратор? Потому что невозможно параллельно работать в EDT и конфигураторе. EDT Выгружает Xml и меняет теги местами что в git отражается как изменением файлов.

Из-за этого edt В принципе не применима в нормальной работе.

В платформенной выгрузке могут быть отличия от того, как это выгружает конфигуратор, но на формат EDT это влиять не должно. Но платформенные выгрузки не хранят в гите. Ранее уже правились баги, связанные с неожидаемыми изменениями в файлах в формате EDT. Если есть конкретный пример, то создайте, пожалуйста, на это отдельный баг.

Но платформенные выгрузки не хранят в гите.

@omankit , cогласна с @vadimeg , даже между релизами одной платформы структура XML при выгрузке из конфигурации "пляшет", что уж говорить про разные платформы, именно поэтому и был придуман формат EDT, которые нивелирует эти различия для хранения в Git. И именно по этому у нас есть возможность сравнивать и сливать по базе ветки, хранящиеся в разных форматах платформы, даже если все три коммита сделаны разными версиями платформ.

Из-за этого edt В принципе не применима в нормальной работе.

Мы применяем, вполне успешно уже 6й год, начиная 2018го в 2020м перешли со смешанного формата, когда ещё основная ветка была хранилищем 1С, на то, чтобы отказаться от хранилища 1С полностью, и все доработки, даже без EDT хранить в формате EDT в Git, научились даже бороться с фантомными изменениями при загрузке изменений от тех разработчиков, которые делают доработки в конфигураторе.

Исправлено в 2024.1

Перенесено в релиз 2023.3

1C-Company / 1c-edt-issues