Добрый день! 



Настраиваем журнал изменений (ChangeLog) для каждого объекта. После настройки в конфигурациях в пакете Custom создается замещающий объект, текущий пакет (CurrentPackageId) у нас не Custom. Как сделать так, чтобы настройки Журнала изменений сохранялись в текущем пакете?

 

Меняли CustomPackageUId -- не помогло. В конфигурации объекта ставили галку «Вести журнал изменений» -- Журнал включается, но после того, как настраиваешь поля, все равно создается замещающий объект в Custom.

 

Заранее благодарю за ответ

Нравится

2 комментария
Лучший ответ

Вадим, добрый день!

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

Сохранение настроек журнала изменений через интерфейс соответствующего раздела технически работает так, что в любом случае в пакете Custom создаётся замещающий объект, вне зависимости от значения настройки Текущий пакет.

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

Проставить признак "Вести журнал изменений" нужно не только объекту, но и журналируемым полям. Обращаю Ваше внимание на то, что при проставлении этих галочек все изменения в объекте должны сохранятся в тот пакет, в котором создан объект.

Вадим, добрый день!

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

Сохранение настроек журнала изменений через интерфейс соответствующего раздела технически работает так, что в любом случае в пакете Custom создаётся замещающий объект, вне зависимости от значения настройки Текущий пакет.

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

Проставить признак "Вести журнал изменений" нужно не только объекту, но и журналируемым полям. Обращаю Ваше внимание на то, что при проставлении этих галочек все изменения в объекте должны сохранятся в тот пакет, в котором создан объект.

Благодарю за ответ!

Показать все комментарии

Привет.

Как использовать события таблицы Журнала изменений(ЖИ) как начальных событий для запуска БП?



Известно что это идут таблицы которые не имеют своего в Entity ORM, с названием - "Sys[TableName]Log" и специальным атрибутом в метаданных таблицы - "TS.EntitySchema.Kind=TrackChangesInDB;".



Тут два пути как я вижу: 

1. "Как-то" сделать  Entity из уже существующей таблицы ЖИ в БД. Но как? 

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

Нравится

2 комментария

Вероятно записи в эту таблицу попадают прямым инсертом в БД, то есть вообще мимо событийного слоя приложения. В таком случае на помощь придут триггеры в БД.

Vyacheslav Lipatkin,

не считаю хорошей идеей на уровне триггеров как-то задействовать бизнес слой. Лучше всего наверное создание журнала кастомного как у Campaign.

Показать все комментарии
Предлагаю проголосовать: нужен ли нам changelog для продуктов Террасофт (тройка и BPM) - отдельно для платформ, отдельно для конфигураций?Что бы я хотел там видеть: - добавленный и убранный функционал в ядре, исправленные в нем ошибки - добавленный, переделанный функционал (в базовых версиях) - хотя бы на уровне логики. Я бы, конечно, хотел видеть changelog вплоть до функций скриптов, но это, наверное, перебор Например, осуществляя переход 3.4.0 - 3.4.1 я потратил довольно много времени на разбор обновлений раздела и деталей продуктов. Происходило это примерно так: "Ооо, они вот что добавили)", "Хм, и тут тоже переделали...", "И вот тут еще(...", "О господи, я лучше заново сделаю((" Это я не к тому, что плохо сделано, а потому, что конкретно нам это оказалось не нужно, а встраиваться туда оказалось сложнее, чем сделать заново. Но время и силы я на это потратил, а вместе с ними потерялась и некоторая часть моей лояльности Я ни за что не поверю, что Террасофт не в состоянии агрегировать производимые изменения, более того, я уверен, что changelog где-то есть, но нам почему-то не показывается
8 комментариев

Да это стопроцентно нужно. Иной раз не знаешь исправлена ошибка из предыдущей версии или нет и приходится раз за разом теребить тех поддержку. Тем более сама тех поддержка иногда не в курсе произошедших изменений.

Есть раздел Релизы систем Terrasoft, но там почему-то как раз 3.4.1 нет, о новом в ней статьи отдельно: 1, 2, 3, 4.

"Зверев Александр" написал:

Есть раздел Релизы систем Terrasoft, но там почему-то как раз 3.4.1 нет, о новом в ней статьи отдельно: 1, 2, 3, 4.


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

Я думаю, что всем, кто имеет дело с разными версиями продуктов, было бы удобно и полезно знать, что, например, переработаны сервисы такие-то и добавлена логика такая-то в таких-то разделах\карточках\деталях. Не обязательно углубляться, но как-то обозначить все же надо.
И раздел сайта или форума - не самое лучшее для этого место. Лучшего способа, чем класть changelog в дистрибутив, я не вижу

Уже была подобная идея.

"Репко Артём" написал:

Уже была подобная идея.

каюсь, не нашел
НО
во-первых, если судить по состоянию раздела http://www.community.terrasoft.ru/resources/partners/general/changes, то никто этим не занимается
во-вторых, я все же настаиваю на файле в дистрибутиве. Получил дистрибутив (обновление бинарников) - посмотрел, что изменилось. Информация на сайте, имхо, вторична
и в-третьих, тогда речь шла только о тройке

Горячо поддерживаю идею с файлом в дистрибутиве!
Ну или хотя бы обновление данных там: http://www.community.terrasoft.ru/resources/partners/general/changes/52…

+1

Идея из того топика может и реализована, но как говорят, не в полной мере (не могу проверить, нет доступа). Я бы тоже хотел видеть списки изменений. Ведь не только партнерам эта информация важна, а и разработчикам на местах. Система открытая для разработки, тогда и проведенные изменения должны быть открыты.

Я тоже за идею с файлом в дистрибутиве

Показать все комментарии