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

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

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

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

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

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

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

Vyacheslav Lipatkin,

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

Егор, добрый день!

Обычно такие задачи решаются с помощью самого журнала аудита (не журнала изменений). Но сейчас в системе не логируется изменение настроек журнала изменений (я создала соответствующую идею в беклоге профильной команды). Список логируемых операций можно посмотреть тут: https://academy.terrasoft.ru/documents/studio/7-12/razdel-zhurnal-audita

В качестве обходного решения можно сделать следуюшее:

1. Для анализа текущей ситуации проанализировать логи приложения (там должны быть видны соответсвующие запросы) и сравнить с данными по сессиям пользователей.

2. На будущее реализовать собственный тригер на уровне БД, который будет писать в лог, если кто-то будет менять настройки журнала изменений.

Старун Юлия,

спасибо за развернутый ответ!

Юлия, можете еще подсказать на какую таблицу вешать триггер чтобы отследить изменение настроек журнала изменений?

Настройка - по каким полям ведется логирование в таблицу SysContactLog.

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

        {
          "UId": "736c30a7-c0ec-4fa9-b034-2552b319b633",
          "Name": "Name",
          "CreatedInSchemaUId": "11ab4bcb-9b23-4b6d-9c86-520fae925d75",
          "ModifiedInSchemaUId": "4cbdc6f3-625d-4639-92bf-bb19d4c9d58e",
          "CreatedInPackageId": "66e9e705-64b4-4dda-925e-d1e05a389eb6",
          "DataValueTypeUId": "ddb3a1ee-07e8-4d62-b7a9-d0e618b00fbd",
          "RequirementType": 1,
          "IsTrackChangesInDB": true,
          "IsLocalizable": true
        },

Но вот на уровне базы данных это уже хранится в колонке MetaData таблицы SysSchema в не таком удобном виде. Там следует искать код Е16, чтобы понять, колонка с каким UID логируется:

Таким образом, триггер нужно вешать на таблицу SysSchema на колонку MetaData по тому объекту, который вы хотите отследить. И сохранять весь текст метаданных, а потом уже анализировать его вручную. Наверное, можно даже посмотреть, какой запрос отправляет система в БД при открытии страницы настроек журнала изменений - там наверняка есть встроенные механизмы парсинга этих данных.

В общем я постараюсь повысить приоритет реализации логирования этих изменений через журнал аудита средствами системы :)

Здравствуйте, Евгений!

1. Уточните, пожалуйста, где Вы смотрите, что не был добавлен пункт [Отслеживать изменения]?
2. Каким образом Вы создавали поле?
3. Полное название Вашей версии (после 3.3.2 ещё есть цифры).
4. Продемонстрируйте проблему с помощью скриншотов.

Добрый день Евгений!!!

в разделе "Журнал изменений БД" есть действие (Вызывается из меню "Действия") - "Настройка журнала изменений БД". Нажав на данное действие открывается окно:

Нажав в данном окне "Добавить" и выбрав требуемую таблицу. Появляется окно:

В появившемся окне "Добавление таблицы" - отмечаем галочками по каким полям "Отслеживать изменения", а какие поля "Отображать в реестре". Вот как раз галочка "Отображать в реестре" и говорит о том, что вы увидите данное поле в Гриде "Журнал изменений БД". Так как можно вести отслеживание изменения по 10 полям, а видеть я хочу для анализа только 5 полей в реестре.

Версия 3.3.2.311.

Поле добавлял с помощью Terrasoft Administrator, а после заполнения поля данными, поставил пункт "Отслеживать изменения" в Terrasoft Administrator.

Пункта "Отображать в реестре"(скриншот 2) нету.

Стоит только переименовать поле, в Журнале изменений сразу же появляется.

Здравствуйте,

к сожалению скриншота нет, чтобы понять о чем идет речь.
Рекомендую ознакомиться с документацией по настройке логирования изменений, смт. на странице 147, глава [Логирование изменений].

Первые три скриншота это пример того как не отображается.

Последние три скриншота, это после изменения названия поля в таблице контактов.

Для устранения этой проблемы необходимо в функции BuildChangesLogWindow сервиса scr_DatabaseLogUtils заменить код

			if ((TableField.SQLName.search(/ID$/ig) > -1) &&
				(TableField.SQLDataType != sdtEnum)) {	// Enums accepted
				continue;
			}

на

			if (((TableField.SQLDataType == sdtGUID) ||
				(TableField.SQLDataType == sdtIdentity)) &&
				(TableField.SQLDataType != sdtEnum)) {  // Enums accepted
				continue;
			}

Павел, спасибо огромное, вы меня спасли

По поводу вопроса с журналом изменений по конкретной записи увидела, что необходимо добавлять деталь самостоятельно
тема http://www.community.terrasoft.ru/forum/topic/12526

Хотя, на мой взгляд, было бы логично, если бы деталь включалась бы автоматически.

А что по поводу просмотра, какие именно поля менялись? Причем, насколько я вижу через sql, история изменения этих полей записывается - но только почему-то не выводится в клиенте такая информация

Дарья, здравствуйте.

Когда Вы настраиваете журнал изменений, Вы выбираете колонки для логирования.

После того, как добавите деталь, Вы можете вывести в реестр настроенные колонки.

Отсортируйте по дате изменения и смотрите, какие колонки были изменены.

Добрый день! Спасибо
Тогда вопрос по добавлению детали
В теме http://www.community.terrasoft.ru/forum/topic/12526
предлагается создать в конфигурации объект представления VwSysContactLog, и скрипт для создания представления в бд.
Этот объект надо унаследовать от другого какого-то объекта?
На принтскрине в объекте перечислены следующие поля ID, Name, ChangeTracked.
ChangeTracked - это справочник судя по всему - на какой справочник ссылка должна быть?
Id - это уникальный идентификатор, не вижу такой тип поля при добавлении поля в объект, как его добавить?
Если я хочу на деталь выводить колонки для логирования, такие как ответственный, статус и т.п., мне тогда нужно добавить их как поля в этот объект представления?

Дарья, здравствуйте!

1. Если Вы присмотритесь внимательно, то по скриншотам видно, что:

- Родительский объект не указан;
- ID указан, который был добавлен руками как новая колонка (уникальный идентификатор).

2. ChangeTracked – это ссылка на логируемый объект.

3. Отображение колонок зависит, от того как Вы настроите логирование объекта в журнале изменений. Отобразите колонки, которые Вам нужны.

«Поигратесь» создавать объект на основании представления экспериментальным путем и в результате все станет ясно.

Спасибо - с деталью получилось вывести колонки.

Остался вопрос по общему журналу изменений.

В журнале есть действие "Показать все изменения выделенной записи".
Я так понимаю, непосредственно с этим действием связана страница «RecordAllChangesGridPage»
из темы http://www.community.terrasoft.ru/forum/topic/13020
Вижу, что в функции идет окрашивание записи в целом(красная,синяя,зеленая)
и окрашивание одного поля в реестре(т.е. логируемого поля, если его значение изменено),
но эта ветка из форума по 5.х

Получается, что в 5.х в форму действия "Показать все изменения выделенной записи" можно каким-то образом вывести логируемые колонки в форму этого действия (раз в схеме прописана их подсветка),
а в 7.х подобный функционал еще не появился. Правильно ли я понимаю?

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

Можно ли ориентироваться на подобный код из 5.х, который вы приводили
в теме http://www.community.terrasoft.ru/forum/topic/13020

var cellsBackground = new Dictionary();
if (PreviousRow != null && HighlightColumns) {
var previousRow = PreviousRow as Entity;
foreach (var column in row.Schema.Columns) {
if ((column.Name != "ModifiedOn") && (column.Name != "ModifiedBy")
&& (column.Name != "ChangeTrackedBy") && (column.Name != "ChangeTrackedOn")
&& (column.Name != "ChangeType")) {
object currentValue = row.GetColumnValue(column.Name);
object prevValue = previousRow.GetColumnValue(column.Name);
if (!Object.Equals(currentValue, prevValue)) {
cellsBackground.Add(column.Name, new DataSourceRowColumnBackgroundColorConfigValue("#FFF30F"));
}
}
}
}
PreviousRow = row;
config.AddConfig(new DataSourceRowColorConfigValue(backgroundColor));
config.AddConfig(new DataSourceRowColumnsBackgroundColorConfigValue(cellsBackground));
return config;
}
Или же принципы подсветки поля в 7.х другие?
Можно ли в 7. отображать другим цветом одно поле в реестре, или подобная возможность есть только в 5.х пока?

Дарья, ниже приведен пример как реализовать подсветку записей.

Цель: Реализовать подсветку записей реестра если у продажи на объекте поле IsNotInterest= true
Реализация:

Создаем метод gridRecolor.

gridRecolor: function () {
   var gridData = this.getGridData();
   var items = gridData.getItems();
   var loadedObject = {};
   Terrasoft.each(items, function (item) {
      item.customStyle = null;
      var facilityId = item.get("Facility").value;
      var opportunityId = item.get("Opportunity").value;
      var isNotInterest = item.get("IsNotInterest");
      //Если условие подходит, меняем цвет записи на темно-серый.
      if (isNotInterest) {
         item.customStyle = {
           'color' : "darkgrey"
         }
      }
      var primaryValue = item.get(item.primaryColumnName);
      //Формируем новый набор данных уже с подсветкой
      loadedObject[primaryValue] = item;
   }, this);
   gridData.clear();
   //загружаем новый набор данных
   gridData.loadAll(loadedObject);
},

Замещаем метод onGridDataLoaded, добавив в него вызов gridRecolor

onGridDataLoaded: function () {
   this.callParent(arguments);
   this.gridRecolor();
},

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

Добрый день!
Спасибо, я видела этот пример - он подсвечивает всю запись реестра.
Мой вопрос был в том - можно ли сейчас подсветить отдельное поле(ячейку) в реестре в 7.х ( в 5.х как я вижу была такая возможность). Только запись можно целиком, получается?

и правильно ли я понимаю, что в общем журнале изменений в 7.х сейчас не получится посмотреть, что именно изменено ( только если деталь сделать):

"Получается, что в 5.х в форму действия "Показать все изменения выделенной записи" можно каким-то образом вывести логируемые колонки в форму этого действия (раз в схеме прописана их подсветка),
а в 7.х подобный функционал еще не появился. Правильно ли я понимаю?"

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

Ясно, спасибо

Спасибо

Мне кажется, такое можно сделать и на уровне страницы реестра детали.
Вбил в поиск по исходникам кофигурации слово «DataSourceRowColorConfigValue», нашло такое.
На ините GridPage:

Page.TreeGrid.GetRowConfigHandler += delegate(Entity row) {	
	var delegation = row as ApprovalDelegation;
	var config = new DataSourceRowConfig(delegation.Id.ToString());
	var currentDate = UserConnection.CurrentUser.GetCurrentDateTime();
 
	if(delegation.EndDate.Date < currentDate.Date)
	{
        config.AddConfig(new DataSourceRowColorConfigValue("Grey"));
	}
	return config;
};

Похоже, оно тоже раскрашивает в зависимости от значения поля. Тут «ApprovalDelegation» — просто объект, используемый в DataSource детали.

Для детали журнала используется страница «Страница реестра истории изменений объектов».
Будьте осторожны, она может использоваться в разных разделах. Если хотите раскрасить только для обращений, надо будет добавить проверку.

Вдалося ідентифікувати модуль: "RecordAllChangesGridPage".

Доброго дня, 

На жаль, базовими засобами додатку це реалізувати неможливо, але ми вже передали це побажання відповідальній R&D команді, для реалізації такої можливості в майбутнії версіях додатку.  

Здравствуйте, Антонина!

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

Спасибо. Давайте так и сделаем.

Спасибо. Давайте так и сделаем.

Как оказалось, дело вот в чём:

Чтобы в запись журнала изменений попадали значения полей, нужно выдать этому пользователю или одной из его групп (например, группе «Все пользователи») права на объект (вкладка «Доступ к объекту», см. на скриншоте). Нужно выдать все 4 права: чтение, изменение, добавление, удаление.

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

Добрый день, Владимир!
Протестировал на указанной верссии. Результат положительный - Журнал работает.

Настройки журналирования:

Журнал изменений (создан контакт TEST и переименован в TEST Changed):

Нужно больше информации:
- включена ли опция слежения за изменениями для сервися таблицы (в TSAdmin)?
- выполнена ли настройка журнаирования?
- имеются ли доработки конфигурации?
- работал ли раньше функционал? Не работает ли сейчас для всех разделов или только выборочно?

Здравствуйте Павел!

включена ли опция слежения за изменениями для сервися таблицы (в TSAdmin)? - включена для сервиса таблицы и для отслеживаемых полей.

выполнена ли настройка журналирования? Выполнена для двух разделов: Контакт и созданный мною раздел TechViewAct. Для раздела Контакт деталь работает. Для раздела TechViewAct - деталь мертвая.
Пытался проверять запрос sq_TechVewActLog - ошибку не выдает и информацию отбирает, но в детали она не отображается.

Раньше этот функционал не проверялся.

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

В качестве тестирования выпонил следующие действия:
1) Создал раздел при мощи утилиты TSCRM.exe /wnd=wnd_CreateNewWorkspace

2) Открыл в Админке таблицу раздела, и установил опцию слежения:

3) Запустил клиента, вошел в настройки журналирования:

4) Включил слежение за изменением поля "Название":
5) Создал запись в разделе и переименовал ее. Проверил журнал.

Для того чтобы прояснить ситуацию с проблемой в данном случае понадобится копия БД.
Журналирование работает на хранимых процедурах. Анализа только лишь серивисов может быть недостаточно.

Здравствуйте Павел!
Реализовал журнал изменений еще для одного вновь созданного раздела - та же история. Правда, я создавал новые раздел без использования сервиса TSCRM.exe /wnd=wnd_CreateNewWorkspace. Отредактировал вновь созданные разделы с использованием этого сервиса в соотвествии с вашими рекомендациями, сравнивал с разделом Контакт, разницы не вижу. Копию БД прислать не смогу из-за ее колоссального объема, но удаленное управление - можно. Когда-то я предоставлял это Яворскому.

Добрый день, владимир.
Выложите, пожалуйста, сервисы Вашего раздела, или направьте нам на support@terrasoft.ru с сылкой на данную ветку форума.

Высылаю.

Владимир, мне удалось вгрузить Ваши сервисы, но протестировать - нет.
Очень много связей ошибок возникает из-за отсутсвующих связей, отсутствует сервис scr_UserIdentification. Вы выгрузили сервисы из действиущего раздела?

Для ускорения решения и оптимизации нашей с Вами работы предлагаю следующие варианты:

1. Создать раздел через утилиту wnd_CreateNewWorkspace, протестировать интересующий Вас функционал. Перенести конфигурационные изменения из Вашего раздела в созданный через wnd_CreateNewWorkspace.
2. Предоставить нам резервную копию БД

Добрый день!
Попробуем оттестировать у себя. Сообщим в ближайшее время результат.

Здравствуйте!

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

Добрый день, Анна!

Я уж и не надеялся получить ответа. Спасибо что откликнулись.

Только что еще раз проверил, что все внешние ключи как в таблице, так и в сервисе таблицы присутствуют. С вероятностью 99% скажу что на момент установки галочки <Отслеживать изменения> они тоже присутствовали. Можно, конечно, попробовать пересоздать эти журналы еще раз. Но как это можно сделать безболезненно, не потеряв того, что накопилось в логах?

Я рекомендовала бы сделать резервную копию БД и экспериментировать на ней, если это возможно.

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

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

Здравствуйте. Сделайте, пожалуйста, запрос с корпоративного e-mail в поддержку (support@terrasoft.ru) для получения последней сборки.