Очень сложная задача?

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

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

В поле "Параметр" необходимо указать параметр из справочника Amenity (Параметр). В зависимости от типа параметра, необходимо заполнить одно из полей Value.

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

Я не нашел в конфигурации объект AmenityInObject.
У нас версия 7.6, может поэтому?

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

Добрый день!

В 7.6 название объекта – AmenityInObject, заголовок объекта – “Значение параметра объекта или листинга ”.

"Зарицкий Олег Васильевич" написал:В 7.6 название объекта – AmenityInObject, заголовок объекта – “Значение параметра объекта или листинга ”.

Есть еще вопрос:
Допустим у нас должен быть логический параметр Архив со значением True. Значение его берем из поля на объекте недвижимости Архив.
Какие именно поля надо заполнить? Как я понимаю это: Листинг, Булёвое значение и название самого параметра. Вот с названием самого параметра и есть вопрос, какое поле за это отвечает? И как его заполнить? Просто же не введешь Архив, тогда ругается при публикации.

Добрый день!

Следует заполнить поля:
1. Параметр – выбрать значение из справочника. (В справочнике хранятся названия всех параметров)
2. Если тип параметра булевое – заполнить поле “Булевое значение”.

Вот такой у меня тестовый БП: http://cs625420.vk.me/v625420418/4b301/gkrBd50hcY8.jpg

Листинг создает, данные в него вносятся. Но вот параметры нет. Что я делаю не правильно?
Данный параметр настроен что бы показывался в любом типе листинга.

Добрый день!

Колонка “Булевое значение” принимает значения true/false. Во вложении пример процесса по созданию листинга и параметра (БП создан в версии 7.6).
usrlistwithparam.rar

Это понятно, но надо в Параметр передать значение. В данном случает брать из логического поля ТОРГ на объекте недвижимости.

Где именно переменные? В БП? Там есть параметры. Через Сценарий просто присвой вот так:

var myString = ReadObj.ResultEntity.GetTypedColumnValue("Name");
MyParam = myString.ToString();

Где ReadObj это чтение данных

Опишу более подробно.
Создал схему-исходный код. В ней я описал свой класс(reqwest).в который должны передаваться параметры. Допустим сейчас только email добавляемого лида.
Создаю задание сценарий. В нем:

var myClass = new BPM.Program(); //создал
myClass.reqwest(email); //вызываю с параметром.

Вот меня интересует, как я должен задать email, чтоб значение бралось из лида?

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

Если Вы используете версию 7.7.0, тогда:

var myClass = new BPM.Program(); 
var email = Get<String>("Email"); /*Email параметр процесса*/
myClass.reqwest(email);

Если Вы используете версию 7.6.0 и младше, тогда просто:

var myClass = new BPM.Program(); 
myClass.reqwest(Email); /*Email параметр процесса*/

Спасибо большое, думал все намного сложнее.
Со всем разобрался

Виталий, этот вопрос рассматривался тут.

Вас понял - буду тестировать. Спасибо!

Пока что 2 вопроса:
1) Какую родительскую страницу указывать для самой страницы детали (т.е. самый верхний объект)? Тоже страницу реестра файлов к комментариям?
2) Какой объект указывать при добавлении детали? Таблицы у меня 2, а объект можно указать лишь один.

1. В примере по ссылке «Cтраница реестра комментариев» унаследована от «Базовая страница реестра».
2. Для детали там указан объект «Комментарий».

Впрочем, не уверен, что в этом примере детали именно независимые.

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

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

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

"Мотков Илья" написал:

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

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

Спасибо, после отключения триггера, обновление данных завершилось успешно.

Спасибо за решение.



А подскажите, пожалуйста, как включение и выключение триггера добавить в пакет, чтобы не выполнять эти скрипты каждый раз вручную?



Отключать триггер, наверное можно "Before saving package", а вот когда включать?



И второй вопрос - почему импорт SysAdminUnit выполняется так долго (50 минут, хотя в данных всего около 20 ролей и 10 пользователей)? Может быть, можно ещё что-то отключить и выполнить единоразово после всего импорта?

 

2020-10-29 17:19:06,697 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "States_Provinces" from package "Exactly.Data" installed
2020-10-29 18:05:40,163 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "SysAdminUnit" from package "Exactly.Data" installed

Ну, наверно, если отключать на «Before», то включать на «After». Такой вариант тоже есть:

А что может так сильно тормозить этот импорт?

Всё, что угодно, например, ещё какие-то триггеры, которые не отключили (и, возможно, отключать и не стоит). Попробуйте посмотреть в SQL-профайлере на отрабатывающие запросы.

Тщательно протестировали. Триггер не отключается перед установкой почему-то на Before...

Ясно. Выходит, сначала идёт AfterPackage и уже затем AfterSchemaData.

Но при этом иногда стала появляться такая ошибка из того же триггера:

 @Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists



То есть, кажется, он успевает включиться до того, как данные начинают импортироваться (пробовали и After package saved, и After Schema data saved.

Если убрать включение триггера, то всё проходит без ошибок. Но кто тогда будет включать триггер?

Судя по RootAlreadyExists, ругается на какую-то конкретную запись, которую считает корневой. Всё ли правильно в залитом? А если в скрипте перед включением триггера задержку вставить?

Да, сначала даже подумал, что в пакете какие-то записи с пустым ParentRoleId. Но посмотрел - нет таких.

Возможно, что при импорте данных что-то дёргает уже существующие All employees, и потому срабатывает триггер.



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

Насчёт задержки была мысль, но тут второй непонятный вопрос - иногда эти данные SysAdminUnit импортируются 5 минут, иногда час, иногда два... И это при том, что их штук 20 всего.



Но после импорта SysAdminUnit и SysUserInRole хорошо бы запустить процедуру tsp_ActualizeAdminUnitInRole. Но пока тоже не совсем понятно, куда её воткнуть...

	IF (TG_OP = 'INSERT' OR TG_OP = 'UPDATE') AND TG_WHEN = 'AFTER' THEN
		IF (NEW."ParentRoleId" IS NULL AND NEW."SysAdminUnitTypeValue" < 4) THEN 
 
			IF (NEW."SysAdminUnitTypeValue" > 0) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.InvalidRootType';
				ROLLBACK;
			END IF;
 
			SELECT COUNT("Id") INTO RecordsCount FROM "SysAdminUnit"
				WHERE "ParentRoleId" IS NULL
					AND "SysAdminUnitTypeValue" < 4
					AND "SysAdminUnit"."Id" <> NEW."Id";
 
			IF (RecordsCount > 1) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists';
				ROLLBACK;
			END IF;
 
		END IF;
	END IF;

Если импорт выполняется долго по непонятной причине, попробуйте смотреть в профайлере, что за запросы долго работают.

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

Вероятно, ту функцию актуализации, которую хотите запустить, нужно тоже на одном из «After...».

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

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

С помощью элемента бизнес-процесса можно раздавать права после сохранения записи. И по первому ответственному, и по второму, по другим полям, и по целым группам

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

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

Поле пропадет из фильтров и его нельзя будет отобразить, используя "Вид"->"Настройка колонок".

"Демьяник Алексей" написал:В свойствах поля (справа) укажите в поле "Режим использования" - "Никогда".

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

На уровне раздела - ничем. Поле будет доступно в фильтре, а также при настройке реестра/страницы редактирования.
Отличие есть только на уровне объекта - поле со свойством "Расширенный" не будет отображаться при открытии объекта. Для его отображения необходимо будет включить в настройках "Показывать системные колонки".

Алексей, спасибо!

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

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

Примерный алгоритм:
Вы пишите отдельный сайт, на страницу с параметрами которого вы будете оставлять ссылку в рассылке.
По инициализации страницы на сайте, будете пользователю показывать окно с выбором файла, далее, используя эти параметры будете в бекенде использовать Odata для записи файла в систему:
http://academy.terrasoft.ua/documents/docs/technic/SDK/7.4.1/WorkWithBp…

Дарья, а почему Вы не хотите вывести данной поле на PortalCasePage мастером разделов?

Александр
поле выглядит вот так

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

Добавили новую вкладку в карточке портального обращения, и вывели там поле "Решение" как текст(недоступный для редактирования)

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

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

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

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

{
		"operation": "insert",
		"name": "UsrNotes",
		"values": {
			"layout": {
				"column": 0,
				"row": 2,
				"colSpan": 12,
				"rowSpan": 2 // <- высота
			},
			"bindTo": "UsrNotes",
			"caption": {
				"bindTo": "Resources.Strings.TestCaption"
			},
			"textSize": 0,
			"contentType": 0,
			"labelConfig": {
				"visible": true
			},
			"enabled": true
		},
		"parentName": "Header",
		"propertyName": "items",
		"index": 5
	},

Что бы оно стало RICH_TEXT, с панелькой применения стилей,
достаточно поменять contentType на:

"contentType": Terrasoft.ContentType.RICH_TEXT

Отключить лейбл так:

"labelConfig": {
        "visible": false
       },

Что бы можно было работать с картинками в этом поле, необходимо добавить:

"controlConfig": {
        "imageLoaded": {
         "bindTo": "insertImagesToNotes"
        },
        "images": {
         "bindTo": "NotesImagesCollection"
        }
}

С именами методов как в основной схеме портальной страницы. Текущий пример взят по примеру поля "Примечания".

Максим, спасибо, мы уже добавили

"Александр Зубков" написал: а почему Вы не хотите вывести данной поле на PortalCasePage мастером разделов?

А как мастером разделов добраться до PortalCasePage?

"Владимир Соколов" написал:А как мастером разделов добраться до PortalCasePage?

Реализуйте через бизнес-процесс, используя элемент email. Вот в этой теме подробно рассмотрен вопрос http://www.community.terrasoft.ru/blogs/12527

Здравствуйте, Мария. Большое спасибо за помощь.
БП построил, однако, проблема с начальным сигналом. Условие план.дата выполнения = сегодня. В этот же день всё работает сообщение отправляет, но на следующий день процесс не запускается. Подскажите как можно решить проблему?

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

Предоставьте, пожалуйста, текущую реализацию Вашего процесса.

"Демьяник Алексей" написал:

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

Предоставьте, пожалуйста, текущую реализацию Вашего процесса.

[URL=http://radikal.ru/big/14793b80a94440afb6bbbd55ced48e19][IMG]http://s020…]
[URL=http://radikal.ru/big/e3040536d8184311a36e5f40e5fc0dcc][IMG]http://s017…]

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

Это логично - ведь завтра при изменении записи не сработает условие "План. завершение" равно Сегодня. Удалите это условие и все заработает.

"Демьяник Алексей" написал:

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

Это логично - ведь завтра при изменении записи не сработает условие "План. завершение" равно Сегодня. Удалите это условие и все заработает.

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

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

"Демьяник Алексей" написал:

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

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

Быть может есть другой способ, чтобы БП работал без перебоя и в нужный день отправлял уведомления на почту?

Используйте планировщик Quartz.
Процесс будет запускаться ежедневно и отправлять одно письмо в день. Более подробно о реализации здесь.

"Демьяник Алексей" написал:

Используйте планировщик Quartz.

Процесс будет запускаться ежедневно и отправлять одно письмо в день. Более подробно о реализации здесь.

А можно по той же системе настроить именно те письма, срок выполнения которых "Сегодня"?

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

Для решения Вашей задачи необходимо создать два процесса:
Process1
1) Стартовый сигнал после "Добавления записи"
2) Чтение данных добавленной записи
Если дата согласования = сегодня, тогда отправляем Email и переходим к пункту 3)
Иначе, переходим к пункту 3)
3) Записать в Quartz на выполнение Process2, передав в параметры RecordId - Id записи документа
4) Конец процесса.

Process2
0) Создать параметр процесса RecordId
1) Начальный элемент
2) Чтение данных документа с фильтром Id == RecordId
Если "Фактическое завершение" заполнено, тогда конец процесса
Иначе, переходи к 3)
3) Чтение данных в режиме количества записей с фильтром:
Id == RecordId
Плановая дата завершения <= Сегодня
Состояние == В работе

Если количество записей == 0, тогда переходим к пункту 5)
Иначе, переходим к пункту 4)

4) Отправить Email
5) Записать в Quartz на выполнение Process2, передав в параметры RecordId - Id записи документа
6) Конец процесса.

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

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

Опишите, пожалуйста, задачу, которую Вы пытаетесь решить?

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

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

Попробуйте при инициализации Вашего раздела получить значение нужного профиля по коду из базы и установить полученное значение в атрибут "Profile" модели раздела. Далее при инициализации колонок реестра (метод initQueryColumns схемы GridUtilitiesV2) вызывается метод getProfileColumns, который должен получить из данного атрибута корректный набор колонок.

Обратите внимание, что перед установкой значения в атрибут "Profile" его необходимо декодировать в объект с помощью Terrasoft.decode.

"Лабьяк Олег Игоревич" написал:

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

Попробуйте при инициализации Вашего раздела получить значение нужного профиля по коду из базы и установить полученное значение в атрибут "Profile" модели раздела...

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

init: function() {
	if (/* условие, по которому необходимо подменять профиль */) {
		this.viewModel = null;
	}
	this.callParent(arguments);
}

Таким способом решить проблему у меня не вышло. Но благодаря Вам я пошел в нужном направлении (по цепочке генерации вью-модели). В итоге вышел на getProfileKey() в SectionModuleV2, что проблему решило. Спасибо огромное!