Если делать свои отчеты, то рано или поздно они расходятся так сильно, что на новый релиз его не адаптировать.
Поэтому если это возможно, я бы в типовых отчетах делал вставки кода, которые были бы хоть как-то объяснимы.

Это не свой отчет, а именно доработка типового для нужд организации из-за особенностей ведения учета. Понятно, что если нужен совсем свой, то взял за основу отчет и дорабатываешь его в свободном стиле. Но я в целом понял, спасибо.

сделать свой отчет = "скопировал типовой и в новом объекте метаданных сделал изменения"

Да, но я хочу связь с типовым сохранить :) чтобы мелкие типовые доработки не вызывали необходимости дорабатывать скопированный отчет. Или оно того не стоит?

Я считаю что копировать типовой отчет и что-то в нем делать - плохая практика. Я лично сталкивался с проблемами при таком подходе.
Поэтому я за то чтобы дорабатывать существующий типовой. Как именно - я выше написал.

Значит я на правильном пути. Осталось определиться с методами :) ещё раз спасибо

Всем привет.
Может кто поделиться опытом ?
—
хочу ДОБАВИТЬ свой пункт в обработку расшифровки (и по левому клику и по правому)
—-
Примеры все приводят К
ОбработкаРасшифровки.ПоказатьВыборДействия(
СП глаголит, что если ДоступныеДействия не указывать - будут доступны все действия
однако на деле без передачи массива - не показывает меню воообще.

Как гит определяет изменения? Есть файл формы. Гит говорит, что он изменился. Пытаюсь закоммитить - получаю "fatal: LF would be replaced by CRLF in". Открываю сравнение с базой - файлы абсолютно одинаковые и окончания у обоих CRLF, открываю в ноуте++, он тоже говорит, что окончания CRLF. Меняю окончания на LF, потом на CRLF - коммит проходит, причем именно проходит, а не пропадает из измененных, хотя изменений я так и не вижу.

Помогло git add --renormalize .

Переносы в файле в репе не говорят о том, что именно так же они сохранены в базе Гита. Я бы чекаутил файл перед визуальной проверкой. Гит при сравнении учитывает будущие преобразования.
Наличие визуального crlf не говорит о том, что ВСЕ переносы такие. 100%, что поле подсказка будет в этом же файле LF. Особенно опасны CR.
Интересно, какое значение настройки eol/crlf ? Менялось?

Буквально на днях искал такой ключ)

едт обновил на сервере, где гитконвертор работает. Гитконвертор перестал работать изза "fatal: LF would be replaced by CRLF in". Настройки не менял. autocrlf=true и safecrlf=true как стояли, так и стоят. Настройки eol/crlf это где?

eol в гитатрибутах имел ввиду

для *.form не стояло, поставил в eol=crlf, но это ничего не дало

Я бы сравнил строки xml из разных версий едт в чистом виде. Особенно те, где LF окажется.

Честно говоря, никогда не пользовался safecrlf.

Если core.safecrlfустановлено значение «true» или «warn», Git проверяет, является ли преобразование обратимым для текущей настройки core.autocrlf. Для «истины» Git отвергает необратимые преобразования;

Судя по описанию, у тебя смешанные переносы, их преобразование является необратимым. Поэтому и ругается.

Поставил в «warn», пусть хотя бы гитконвертор работает. Один фиг у нас на едт никто не перешел еще

А какой тебе прок от этой настройки? В чем польза от safe?

И почему не все в LF, как завещал Никита?))))

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