разобрался

Terrasoft.sdk.Model.setModelEventHandler("Contact", 
	Terrasoft.ModelEvents[Terrasoft.ModelEventKinds.Before].insert,
	function(config, operation) {
		debugger;
		var record = config.scope.eventConfig.records[0];
		window.console.log(config);
		window.console.log(record);
		var addresses = record.ContactAddressDetailV2EmbeddedDetailStore.getData();
		if(addresses.all.length === 0) {
			var exception = new Terrasoft.Exception();
			exception.config.message = "Сообщение";
 
			Ext.callback(config.succes, config.scope, [false]);
		} else {
			Ext.callback(config.success, config.scope, [true]);
		}
		Ext.callback(config.success, config.scope, [true]);
});

Павел, добрый день! Для решения указанной задачи ПРАВИЛЬНЕЕ использовать не встроенные процессы, а клиентский код. Пример можно посмотреть на странице активности (там проверяется, что завершение не может быть меньше начала). Серверный код не стоит использовать, если в результате проверки необходимо запретить клиенту сохранить запись.

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

Юлия, спасибо за ответ. Действительно, я рассматривал вариант отмены на клиенте. С редактируемым реестром более менее работать научился. Но здесь проблема в том, что это справочник. То есть страница редактирования не персональная, а общая. Поэтому и выбрал встроенные БП. Но там, похоже ничего не получится... А задача действительно - запретить изменение полей, а не делать промежуточные вычисления.

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

Сформулирую как я понял задачу:

На странице есть поле. Поле ссылается на справочник. В справочнике есть следующие поля:

• Название (то, что будет отображаться на странице)
• Дата начала
• Дата завершения

На странице есть также поле с типом "Дата" (назовем его "Валидатор"). Необходимо, чтобы выполнялась проверка находится ли значение, указанное в поле "Валидатор" в интервале ["Дата начала", "Дата завершения"].

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

Есть два решения задачи:

• Пользовательское (с использованием мастера бизнес-правил). Доступно, начиная с версии 7.10.0.
• Разработкой доп. логики.

Алексей, здравствуйте.

Задача в следующем. Есть справочник, в котором есть поля Название, Дата начала, Дата окончания. Справочник редактируется в разделе Дизайнер системы - справочники. В этом справочнике необходимо контролировать, чтобы дата окончания не была меньше даты начала. Чтобы при попытке сохранить запись справочника производилась проверка и запись справочника не сохранялась бы при невыполнении условия.

"Для решения указанной задачи ПРАВИЛЬНЕЕ использовать не встроенные процессы, а клиентский код."



- я извиняюсь, а почему это "ПРАВИЛЬНЕЕ"? Потому, что заморачиваться не хочется? А если мне нужно обезопасить данные, чтобы сотрудник не "нахимичил"? Ваша валидация, которая "ПРАВИЛЬНЕЕ", обходится средствами браузера на раз-два. И действительно "ПРАВИЛЬНЕЕ" было бы организовать валидацию на стороне сервера перед сохранением.

Наряду с валидацией в клиентской схеме, можете встроить проверку по событию "Проверка записи" на вкладке "Сохранение" в событийном подпроцессе. Просто при помощи сценария. При невыполнении каких-либо условий пробросьте Exception из сценария.

* Во первых, сообщение ошибки вылезет пользователю на экран в информационном окошке , так что можете сообщить, что не так.

* Во вторых, сохранения точно не произойдёт.

* В третьих, такую проверку пользователь точно не обойдёт.

Какая цель использовать sandbox в рамках одной схемы? Это нельзя, и в этом нет смысла. Используйте колбеки.

Ну юзкейс у такого положения вещей есть:
Уже "притчей во-языцах" становится извечная проблема открытия карточек в Combined и Separated режимах, и добавлением какого либо функционала в верхнее горизонтальное меню.
Приходится описывать свою бизнес-логику как для секции так и для карточки, причем логика в сути идентичная, кроме способа получения данных самой карточки (для секции это отдельные трудности, так как прямого доступа к модели карточки не имеется, разве что через "GridData"), так же секцию выделяет то что там необходимо реагировать на отдельные события инициализации карточки.
Вообщем все это порождает офигенный оверхед по коду.
Решение было найдено через Миксин-модуль и события.
Таким образом специально сконфигурированный миксин можно подключать и к карточке и к схеме - логика описана в едином месте, в едином виде, в сути все происходит в карточке, а секция просто соответствующим образом реагирует и подписывается на ряд событий.
Так вот сейчас приходится разделять Миксин-модуль | Модуль экспортирующий публикации | Модуль экспортирующий подписки.
Ну и проскочила мысль, что сами messages можно в рамках одной схемы объявить (одного миксина) а уже подписываться/публиковать по ситуации в схемах куда миксин подключен.

"Севостьянов Илья Сергеевич" написал:Вообщем все это порождает офигенный оверхед по коду.

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

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

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

Есть два варианта решения:
1) На странице редактирования
2) На стороне сервера по событию изменения записи бизнес-процессом

Пример реализации на стороне страницы редактирования Вы можете посмотреть в схеме OrderProductPageV2:

"PrimaryPrice": {
	dependencies: [
		{
			columns: ["Price", "Amount", "DiscountAmount", "TaxAmount", "TotalAmount"],
			methodName: "calculatePrimaryValues"
		}
	]
}

Значение поля PrimaryPrice изменяется методом calculatePrimaryValues при изменении полей "Price", "Amount", "DiscountAmount", "TaxAmount", "TotalAmount".

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

благодарю за ответ. попробую сделать так.

Сделал по первому способу. Поля устанавливаются, но при нажатии на "Сохранить" значения остаются прежними. Если устанавливать значение справочного поля вручную, то все сохраняется.

Беда, как говорится, не приходит одна.

Приведу примерный механизм изменения данных:

var UsrL = this.get("UsrL");

далее идет поиск нужного значения справочника и установка этого значения в справочное поле

var n =  item.get("Name");
var t = {
	displayValue: n,
	value: UsrLoial.value
};
this.set("UsrL", t);

Для справочника есть следующий метод для установки значения:

this.loadLookupDisplayValue("ИмяСправочника", значение);

Здравствуйте, Алексей!

Ну, наверное, пересчет через процесс - ресурсоемкое удовольствие.

Не легче сделать агреггирующую колонку в реестре раздела "Контакты"?
Как вариант, Вы можете настроить "Итоги" в разделе "Договоры", и построить динамическую группу, в которой Вы будете изменять контакт.

Данная реализация подойдет?:smile:

Здравствуйте, Алексей! :smile:

Отлично, спасибо большое за ответ - да, подойдет.

Относительно ресурсоемкости согласен.

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

Спасибо!

--
С уважением, Алексей Быков.

Здравствуйте Constantine!
Это просто.
У карточки редактирования есть метод: "AreConditionsCorrect". Переопределив его и добавив свою логику (установив Page.[EditControl].Required = true [данный метод установит свойство поле обязательно для заполнения] и панель сообщений сама Вам выведет указанное в описании сообщение со ссылкой на поле) или Вы можете вернуть значение "false" из метода перед этим заполнив MessagePanel, и базовая логика сохранения не отработает.
А лучше, если Вы будете устанавливать свойство обязательности в своей логике, например при смене значения другого поля.
И наконец, почему бы Вам просто не изменить свойство в объекте, установив значение "Обязательно для заполнения на уровне приложения"?

Спасибо за совет, Андрей!
Я видимо не совсем правильно сформулировал саму задачу. Указанное сообщение я упомянул для примера, а логика разрешения/запрета сохранения записи не касается обязательных для заполнения полей.
Буду копать в сторону этого метода

Игорь, возможно, какая-то логика заложена в скрипте датасета контрагента, посмотрите в сервисах
- ds_Account
- scr_Account
события on OnDatasetDataChange, OnDatasetBeforePost, OnDatasetAfterPost.

А таки ж логіка в OnDatasetDataChange в scr_Account.

Здравствуйте Игорь, проблема решена ?

Можливо причина ось у цьому параметрі:
Account.IsUpdating = true;

Загалом проблема знята.
Тільки ще не розібрався в чому власне воня полягала :)