На карточку недвижимости вывести деталь по объекту чаты. В описании детали указать свою функцию в значении filterMethod(пример можно найти в AccountPageV2).

В фильтре указать равенство

[Просмотры недвижимости:Контрагент:Контрагент].Недвижимость = 

Id текущей записи недвижимости (this.get('Id"))

https://academy.terrasoft.ru/docs/7-17/developer/front-end_development/…

Спасибо! Все получилось.

Полозюков Евгений Петрович,

Здравствуйте! а доступ к этой статье только у сертифицированных разработчиков?

Лидия, структура и содержимое справки недавно менялись, теперь см. эту статью.

Решали подобные проблемы. Самое простое - перечитать грид после добавления записи :)

Вариант А:

onProductInsert: function(response) {
 
this.hideBodyMask.call(this);
if (this.get("IsGridLoading")) {
	return;
}
this.beforeLoadGridData();
var filterCollection = [];
response.queryResults.forEach(function(item) {
filterCollection.push(item.id);
});
var esq = this.Ext.create("Terrasoft.EntitySchemaQuery", {
	rootSchemaName: this.entitySchemaName
});
this.initQueryColumns(esq);
esq.filters.add("recordId", Terrasoft.createColumnInFilterWithParameters("Id", filterCollection));
esq.getEntityCollection(function(response) {
	this.afterLoadGridData();
	if (response.success) {
	    var responseCollection = response.collection;
		this.prepareResponseCollection(responseCollection);
		this.getGridData().loadAll(responseCollection);
		this.reloadGridData(); // вот источник проблемы
	}
}, this);
}

Вариант Б - замещайте функцию editRecord:

editRecord: function(record) {
 
	var activeRow = record || this.getActiveRow();
	if (!activeRow) {
		return;
	}
	if (!this.getIsCardValid()) {
		return;
	}
	var isCardChanged = this.getIsCardChanged();
 
 
	// вот тут возникает проблема у вас. Если activeRow не объектного типа, тогда не можем получить его своейство и падаем				
	if (typeof activeRow === "object") {
		var primaryColumnValue = activeRow.get("Id");
	} else {
		var primaryColumnValue = activeRow;
	}
 
    var typeColumnValue = this.getTypeColumnValue(activeRow);
	if (isCardChanged) {
		this.set("CardState", configurationEnums.CardStateV2.EDIT);
		this.set("EditPageUId", typeColumnValue);
		this.set("PrimaryValueUId", primaryColumnValue);
		var args = {
			isSilent: true,
			messageTags: [this.sandbox.id]
		};
		this.sandbox.publish("SaveRecord", args, [this.sandbox.id]);
	} else {
		this.openCard(configurationEnums.CardStateV2.EDIT, typeColumnValue, primaryColumnValue);
	}
}

Но первый способ гарантированно решит проблему. 

Дмитрий, спасибо, первый вариант помог.

Доброго.

называйте их соответственно:
UsrCase и UsrProblemKEDB

Извините, но не поняла.
Кого их?

Вот здесь, что необходимо писать?
//Название объекта для выбора из справочника
config.lookupEntitySchema = config.lookupConfig.entitySchemaName = "Problem";
// название раздела
config.sectionEntitySchema = "Case";

Если написать
//Название объекта для выбора из справочника
config.lookupEntitySchema = config.lookupConfig.entitySchemaName = "UsrProblemKEDB";
// название раздела
config.sectionEntitySchema = "UsrCase";

то ошибка будет

Дарья, уточните, какая ошибка?

вот такая ошибка

Дарья, я буду отталкиваться примера http://www.community.terrasoft.ru/forum/topic/15489#comment-59283.

Для работы необходимо, чтобы был создан объект ReleaseConfItem (развязочная таблица), в котором есть колонки "ConfItem" и "Release", которые в свою очередь ссылаются на базовые объекты "ConfItem" и "Release".

Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты

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

Если колонки UsrCase и UsrProblemKEDB ссылаются на базовые объекты Case и Problem, то для решения Вам необходимо изменить название данных колонок в объекте на соответствующие.

"Мотков Илья" написал:Если колонки UsrCase и UsrProblemKEDB ссылаются на базовые объекты Case и Problem, то для решения Вам необходимо изменить название данных колонок в объекте на соответствующие.

Деталь отрисовывается
Ошибка возникает при нажатии на кнопку Добавить

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

А почему Вы не можете изменить название колонки с UsrCase на Case?

В системе есть системная настройка Префикс названия объекта (код SchemaNamePrefix). Замените в ней значение по умолчанию с "Usr" на "". После этого очистите Redis и перезайдите в систему. Измените название колонки на нужное...

Добрый день! Потому что это не первая пользовательская колонка. И уже есть много колонок, начинающихся на usr, и на которых прописано значительное кол-во логики. Так что не думаю, что это хорошая идея менять префикс. Подскажите, пожалуйста, все же как же создать такую деталь в итоге.

Здравствуйте, к чему эти сложности, если у Вас версия 7+, то достаточно создать объект и воспользоваться мастерами, никакой код писать не нужно.

Ведь пример реализации паттерна многие-ко-многим в bpm’online это просто «детали» в которых есть ссылочные колонки.
detail_wizard

К примеру, в детали «продукт в заказе», есть ссылка на продукт, и связочная с заказом колонка «заказ». И именно таким, у одного заказа может быть множество продуктов. А один и тот же продукт, может фигурировать во множестве заказов.

Перед тем как описать алгоритм, обращу внимание на ошибку со скриншота. Terrasoft.ItemNotFoundException. Это известная ошибка мастеров версии 7.7. Которая будет исправлена в след. версиях. Побороть ее можно так: заходите в конфигуратор, открываете любую схему, именно схему, а не объект, какую-то схему карточки или раздела, и сохраняете ее. Сделайте это перед тем как выполнять алгоритм.

Теперь алгоритм создания детали многие ко многим.

В конфигураторе создаете объект для детали «USRKEDB» или как вам удобно, наследуясь от базового объекта, добавляете туда нужные вам ссылочные колонки. UsrCase и UsrProblemKEDB. Публикуете.

Мастером деталей создаете деталь, указав имя будущей детали и выше созданный объект. Перед тем как сохранять деталь, перейдите на закладку страница, и убедитесь что нет ошибок в открытии этой закладки, и разместите там свои ссылочные существующие поля. Сохраняйте.

После сохранения детали, ее можно зарегистрировать на странице, как понимаю «Case», с помощью мастера разделов:
section_wizard

Указав в качестве колонки детали «UsrCase» в качестве колонки объекта «Id». Сохранить.

В пользовательском режиме настроить отображение колонок грида детали.
Все, У одного Case может быть указано множество Problem. А одна и та же Problem может фигурировать во множестве Case. Никакого кода для этого не понадобилось. Объект, и мастера.

И да, не забывайте чистить кеш браузера, и перезаходить на сайт в процессе "разработки".

Это версия 7.6. Деталь создавалась не мастером. Если создавать деталь мастером, то она унаследуется не от той схемы - не от базовой детали многие-ко-многим. У детали вообще другой функционал будет. Мастером только обычную деталь получается создать.

Какого функционала вам не хватает в предложенном выше варианте? Суть одна и та же. Вы сможете эту деталь вывести как в Обращении, и видеть список проблем.
Так и в проблеме, видеть список обращений, которые случались по проблеме. Что и есть связь многие-ко-многим.

Суть не одна и та же. Базовая деталь многие ко многие отличаются своим функционалом от обычной детали. если б не отличалась, наверное, такой бы схемы вообще не существовало, ведь правда..;? При нажатии кнопки добавить на этой детали должен отражаться выбор записей для привязки. Мастером так создать не получится. Причем здесь обычная деталь, которая создается мастером?

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

Посмотрите реализацию в UIv2.ActivityParticipantDetailV2 метод openContactLookup. Мультивыбор добавляется в config:

var config = {
	entitySchemaName: "Contact",
	multiSelect: true,
	columns: ["JobTitle", "MobilePhone", "Email", "[SysAdminUnit:Contact].Id"]
};

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

Здравствуйте, посмотрите еще раз внимательно как работает деталь участников активности.

"Татаровская Дарья" написал:При нажатии на кнопку добавить не должна открываться форма редактирования, а должен открываться вот такой список записей для присоединения

И это именно связь многие-ко-многим. Один участник во многих активностях. В одной активности много участников. И сделано это на обычной детали с помощью развязочной таблицы + комментарий Алексея.

Использовать схему «Базовая схема детали с реестром со связью многие ко многим» в качестве родительской не рекомендуется так как это устаревшая aspx форма.

Спасибо, Максим, посмотрела.
Непонятно, на самом деле, почему схема многие-ко-многим считается устаревшей, она используется в коробке.

Контактов можно прикреплять к задаче. Не увидела правда, чтобы много задач можно было прикреплять к контакту по аналогии.

Итак, то есть вы предлагаете взять за основу деталь ActivityParticipantDetail?
и сделать детали наподобие нее?
Эта детальвообще ни от какой детали не унаследована.. мне также свою деталь не унаследовать ни от какой? Я правильно понимаю, чтобы сделать деталь многие-ко-многим нужно ее рисовать практически с нуля?
Деталь выглядит причем явно сложнее, чем
стандартная KnowledgeBaseInCaseDetail - Схема детали статей базы знаний в обращениях, которая унаследована от «Базовая схема детали с реестром со связью многие ко многим»
и
стандартная CaseInKnowledgeBaseDetail - Раздел детали обращений в разделе базы знаний, которая унаследована от «Базовая схема детали с реестром со связью многие ко многим».

Но насколько я поняла, в кастомной логике этой базовой простой схемой многие-ко многим воспользоваться невозможно. Это действительно так?

Получается, чтобы сделать допустим, связь многие ко многим между обращениями и проблемами,
нужно создать две детали
ProblemInCaseDetai
l и
CaseInProblemDetail,
не унаследованные ни от какой детали,
а логику в них прописать аналогично логике ActivityParticipantDetail?
Не очень понятно как выводить деталь такую на карточку..

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

Деталь "Активности" - ActivityDetailV2. Там нет логики мультивыбора, так как фильтрация отображаемых записей осуществляется по объекту "Участник активности".

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

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

Спасибо, я знаю, как мастером выводить деталь и как создавать ее без мастера тоже......
Я не это спрашивала))
Проблема в том, что все это были обычные детали.
Сейчас меня интересуют деталь многие-ко многим.

Я хотела взять за основу детали
стандартная KnowledgeBaseInCaseDetail - Схема детали статей базы знаний в обращениях, которая унаследована от «Базовая схема детали с реестром со связью многие ко многим»
и
стандартная CaseInKnowledgeBaseDetail - Раздел детали обращений в разделе базы знаний

и сделать похожие.

Но насколько я поняла, в кастомной логике этой базовой простой схемой многие-ко многим воспользоваться невозможно. Это действительно так?
Очень жалко..(

Вы предлагаете как обходное решение взять за основу деталь ActivityParticipantDetail, я правильно понимаю?
Эта деталь не унаследована ни от какой детали - у нее в графе Родительская деталь пусто.
Мне при создании новой детали (я не буду замещать) тоже не выбрать ни какую родительскую деталь?? даже базовую схему?

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

Схема UIv2.ActivityParticipantDetailV2 наследуется от NUI.BaseGridDetailV2.

Спасибо, теперь понятно

Со связью многие-ко-многим понятно)
А что делать со связью один-ко-многим? и мультивыбором
Развязочной таблицы здесь уже нет.

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

Как действовать в таком случае?
По аналогии с деталью Изменения в в карточке релизах, или с деталью Обращения в карточке изменения поступить не удается ( они унаследованы от один-ко-многим).

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

Я уже запутался... Вы можете привести практический бизнес-кейс, который Вы хотите реализовать?

Добрый день, Алексей!
Бизнес-кейсов два:
1) связь многие-ко-многим
в частности, в рамках обращений и проблем
Необходимо было в обращении указывать статьи KEDB(проблемы), с помощью которых решено было обращение
Данный бизнес-кейс воплощен в жизнь)
За основу взят пример Схема UIv2.ActivityParticipantDetailV2 - участники в активности, развязочная таблица и т.п.
Тут все ок
2) следующий бизнес-кейс
это реализация связи один-ко-многим
Есть карточка обращения, пользовательское поле "Вызвано изменением" (родительское изменение)
и деталь Дочерние обращения(вызванные) в карточке изменения
Эта деталь должна быть со связью один-ко-многим с возможностью мультивыбора

Сделать наподобие CaseChangeDetail - Схема детали "Обращение" раздела "Изменение" не получается, т.к у нее родительская схема Базовая схема детали с реестром со связью один ко многим - она устаревшая, как вы говорили. и опять таки действует ограничение
Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты" ( в начале топика).Но объект-то кастомный, колонки называются с префикса Usr.

Как быть в таком случае?

"Татаровская Дарья" написал:

2) следующий бизнес-кейс

это реализация связи один-ко-многим

Есть карточка обращения, пользовательское поле "Вызвано изменением" (родительское изменение)

и деталь Дочерние обращения(вызванные) в карточке изменения

Эта деталь должна быть со связью один-ко-многим с возможностью мультивыбора

Сделать наподобие CaseChangeDetail - Схема детали "Обращение" раздела "Изменение" не получается, т.к у нее родительская схема Базовая схема детали с реестром со связью один ко многим - она устаревшая, как вы говорили. и опять таки действует ограничение

Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты" ( в начале топика).Но объект-то кастомный, колонки называются с префикса Usr.

Как быть в таком случае?

Так алгоритм реализации аналогичен, согласно иинструкции. Пример. топика, http://www.community.terrasoft.ru/forum/topic/12306#comment-52833

Как вариант:
- В Объекте 1 (Раздел 1) добавляете колонку "Колонка 2" (родительский объект "Объект 2");
- Реализовываете деталь через мастер на основании существующего объекта (Объект 1) в разделе "Разделе 2" (Объект 2).

Также пример можете посмотреть в LeadProductDetailV2.

Добрый день!
Смысл данной записи был в том, что инструкция не подошла.
в инструкции родительская схема Базовая схема детали с реестром со связью один ко многим - она устаревшая, как говорили уже в топике. и опять-таки действует ограничение из инструкции
"Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты" ( в начале топика)".Но объект-то кастомный, колонки называются с префикса Usr.

то есть взять за основу такой способ не получается:
define("CaseChangeDetail", ["ConfigurationEnums"],
function() {
return {
entitySchemaName: "Case",
methods: {
/**
* Инициализирует параметры детали.
*/
initConfig: function() {
this.callParent(arguments);
var config = this.getConfig();
config.lookupEntitySchema = "Case";
config.sectionEntitySchema = "Change";
},
/**
* Выполняет инициализацию.
*/
init: function() {
this.callParent(arguments);
this.initConfig();
},

/**
* Возвращает дополнительные фильтры.
* @protected
* @virtual
* @returns {Terrasoft.FilterGroup} Фильтры.
*/
},
diff: /**SCHEMA_DIFF*/[]/**SCHEMA_DIFF*/
};
}
);

LeadProductDetilV2, спасибо, но он, к сожалению, не подходит, там используется развязочная таблица LeadProduct
- это бизнес-кейс из случая 1 - многие-ко-многим. Как раз бизнес-кейс из случая 1 был реализован именно таким образом

"Татаровская Дарья" написал:
2) следующий бизнес-кейс

это реализация связи один-ко-многим

Есть карточка обращения, пользовательское поле "Вызвано изменением" (родительское изменение)

и деталь Дочерние обращения(вызванные) в карточке изменения

Эта деталь должна быть со связью один-ко-многим с возможностью мультивыбора

Сделать наподобие CaseChangeDetail - Схема детали "Обращение" раздела "Изменение" не получается, т.к у нее родительская схема Базовая схема детали с реестром со связью один ко многим - она устаревшая, как вы говорили. и опять таки действует ограничение

Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты" ( в начале топика).Но объект-то кастомный, колонки называются с префикса Usr.

Как быть в таком случае?

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

Здесь нужна либо развязочная таблица, либо деталь на основании объекта Case со связью Раздел.Вызвано изменением == Деталь.Вызвано изменением.

Первый вариант делается по аналогии, второй - в несколько кликов в дизайнере деталей и в дизайнере раздела Case.

Добрый день, Алексей!
Первый вариант с развязочной таблицей работает, все замечательно.

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

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

Если действовать по аналогии, то получается вот такой код
define("UsrChildCaseChangeDetail", ["ConfigurationEnums"],
function() {
return {
entitySchemaName: "Case",
methods: {

initConfig: function() {
this.callParent(arguments);
var config = this.getConfig();
config.lookupEntitySchema = "Case";
config.sectionEntitySchema = "UsrParentChange";
},

init: function() {
this.callParent(arguments);
this.initConfig();
}

},
diff: []
};
}
);

Деталь опять-таки есть, и даже мультивыбор работает, при выборе заполняется поле UsrParentChange, но на детали данные при этом не отображаются..
Видимо, это связано с тем, что невозможно выполнить следующее условие в инструкции
"Справочные колонки деталей в родительских объектах должны иметь такое же название, как и их объекты" ?
Поле кастомное, и называется в данном случае UsrParentChange...

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

В таком случае, почему Вы не можете переименовать поле в детали, задав ему название родительского? Убрать префикс Usr Вы можете изменив значение системной настройке с кодом SchemaNamePrefix. Если я правильно понимаю, то это поле используется только в детали.

Ну потому что это не единственное пользовательское поле ведь, есть много других полей, у которых есть уже приставка Usr, и что делать с ними, если сменить системную настройку?)

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

Спасибо

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

Тут и так непонятно, а кто-то не может потрудиться сформулировать более адекватное предложение, тогда бы и темы новые не плодились. Нужно было написать так: В промежуточной таблице названия колонок должны иметь имена объектов, на которые они ссылаются (имя колонки в промежуточной таблице = названию раздела и т.д.)