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

Обычно такие задачи решаются с помощью самого журнала аудита (не журнала изменений). Но сейчас в системе не логируется изменение настроек журнала изменений (я создала соответствующую идею в беклоге профильной команды). Список логируемых операций можно посмотреть тут: 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 по тому объекту, который вы хотите отследить. И сохранять весь текст метаданных, а потом уже анализировать его вручную. Наверное, можно даже посмотреть, какой запрос отправляет система в БД при открытии страницы настроек журнала изменений - там наверняка есть встроенные механизмы парсинга этих данных.

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

Разобралась самостоятельно :exclaim:
Возможно, кому-то пригодится эта информация.

Это можно реализовать таким образом:
var config = {
entitySchemaName: "BTVwPCManifest",
multiSelect: true,
sortedColumns: [{
name:"BTNumber",
orderPosition: 0,
orderDirection: Terrasoft.OrderDirection.ASC
}]
};

Решил проблему сам путем добавления в объект SysDateTimeFormat следующей строчки:

insert into SysDateTimeFormat(Name,Code) values('Час','Hour')

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

Для исправления данной ошибки необходимо в замещенной схеме LookupEditPage (Схема страницы редактирования раздела "Справочник") закомментировать или удалить diff SysEntitySchemaUId и diff SysPageSchemaUId:

/*{
		"operation": "insert",
		"name": "SysEntitySchemaUId",
		"values": {
			"layout": {
				"column": 0,
				"row": 5,
				"colSpan": 12,
				"rowSpan": 1
			},
			"bindTo": "SysEntitySchemaUId",
			"caption": {
				"bindTo": "Resources.Strings.SysEntitySchemaUIdCaption"
			},
			"enabled": true
		},
		"parentName": "Header",
		"propertyName": "items",
		"index": 4
	},
	{
		"operation": "insert",
		"name": "SysPageSchemaUId",
		"values": {
			"layout": {
				"column": 0,
				"row": 6,
				"colSpan": 12,
				"rowSpan": 1
			},
			"bindTo": "SysPageSchemaUId",
			"caption": {
				"bindTo": "Resources.Strings.SysPageSchemaUIdCaption"
			},
			"enabled": true
		},
		"parentName": "Header",
		"propertyName": "items",
		"index": 5
	} */

Или же удалите замещенную схему, сгенерируйте исходный код и скомпилируйте конфигурацию.

Если Вы хотите узнать ID конкретного справочника, то выполняйте запрос на уровне БД:

Select * from Lookup
Where Name='Категории контрагентов'

так как подобная информация должна храниться и отображаться только на уровне БД, чтобы избежать подобных ошибок.
Если Вам необходимо все таки отобразить ID объекта, то выведите соответствующую колонку в реестре раздела «Справочники» (Рис. 1).

"Вильшанский Дмитрий" написал:закомментировать или удалить diff SysEntitySchemaUId и diff SysPageSchemaUId

Здравствуйте, Эмин!

Для интеграции с Asterisk рекомендуем использовать BPMonline Agent Desktop 7.2.0.915 и выше.

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

Касательно первого пункта, все верно.

Касательно второго пункта, в системной настройке "Сервер обмена сообщениями" задается строка подключения к Terrasoft Messaging Service. Установлена ли она у Вас? Не рекомендуем в данной настройке использовать localhost, вместо этого используйте ip-адрес сервера, на котором установлена Terrasoft Messaging Service. Правильный вид: ws://ip-адрес:2013 (обратите внимание, что порт не 2011).

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

CTIPanel не отображается из-за того, что соединение с сервером телефонии не установлено.

Также, обратите внимание на то, что на рабочем месте должен быть установлен софтфон, настроенный на ту же учетную запись пользователя телефонии, которая указана в профиле пользователя в пункте настройки Call Centre.

"Резвов Роман" написал:

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

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

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

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

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

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

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

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

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

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