Это решается не привязкой данных, а SQL-скриптом.



Посмотрите, какие Id и SysSchemaId у вас на среде разработки и их вставьте в подобный запрос. А перед эти проверьте, нет ли у вас уже property 'Enabled' для данного процесса (схемы) на среде, куда будете переносить



INSERT INTO "SysSchemaUserProperty"

("Id","Name","Value","SysSchemaId")

VALUES 

('0a16d853-9e01-4544-8a6f-3ebde5d3bbed','Enabled',false,'4944ebb5-1881-46a9-85df-b93d092424ad')

ON CONFLICT DO NOTHING

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

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

Здравствуйте, Сергей!



Данное поведение напоминает ошибку в базовой логике, которая была исправлена в версии 7.15.4. По данному вопросу будет зарегистрирована обращение, в рамках которого будет предоставлено решение.



Пожалуйста, ожидайте, обратной связи.

Станислав Чернышев,

Как раз я работаю на версии 7.15.3.

С нетерпением жду решения данной проблемы.

Сергей Рогов,

Станислав Чернышев,

Не нашлось решения для версии 7.15.3? 

Похоже на баг.

Попробуйте прописать в формулу руками.

[#Основная запись.Ответственный#]

Где Ответственный - название (заголовок) вашего поля.

Артур Матюшок, добрый день!

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

Ручной ввод формулы тоже должен помочь.

Игорь, добрый день.

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

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

В схеме PortalCaseSectionActionsDashboard пакета Portal функция заменена заглушкой:

/**
 * @inheritDoc Terrasoft.DcmSectionActionsDashboardMixin#setDcmAvailableStages
* @overridden
 */
setDcmAvailableStages: this.Terrasoft.emptyFn,

Для исправления в пакете проекта в этой  же схеме вернул код из упомянутого выше миксина:

setDcmAvailableStages: function(actionsItem) {
	const dcmSchema = this.get("DcmSchema");
	const sourceStageUId = actionsItem.get("StageUId");
	const outgoingConnections = dcmSchema.stageConnections.getOutgoingConnections(sourceStageUId);
	const availableStages = outgoingConnections.map(function(connection) {
		const referenceStage = dcmSchema.stages.get(connection.target);
		return referenceStage.stageRecordId;
	});
	actionsItem.set("AvailableStages", availableStages);
},

Теперь стадии переключает.

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

Добрый день.

Для реализации Вам необходимо подписаться на изменение колонки кейса и при её изменении вызывать метод setActiveTab.

Пример реализации для страницы CasePage:

define("CasePage", [], function() {
		return {
			entitySchemaName: "Case",
          	attributes: {
              "ActiveTabName": {
                dependencies: [
                  {
                    columns: ["Status"],
                    methodName: "setActiveTabByStatus"
                  }
                ]
              },
              "StatusTabDictionary": {
                dataValueType: Terrasoft.DataValueType.COLLECTION,
                value: [
                  { statusId: "7e9f1204-f46b-1410-fb9a-0050ba5d6c38", tabName: "CaseInformationTab" },
                  { statusId: "3859c6e7-cbcb-486b-ba53-77808fe6e593", tabName: "TimelineTab" },
                  { statusId: "ae7f411e-f46b-1410-009b-0050ba5d6c38", tabName: "SolutionTab" }
                ]
              }
            },
			methods: {
 
              setActiveTabByStatus: function() {
                var status = this.get("Status");
                if (!status) {
                  return;
                }
 
                var statusTabDictionary = this.get("StatusTabDictionary");
                for (var i = 0; i < statusTabDictionary.length; i++) {
                  var item = statusTabDictionary[i];
                  if (item.statusId === status.value) {
                    this.setActiveTab(item.tabName);
                    return;
                  }
                }
              },
 
              initTabs: function() {
                this.callParent(arguments);
                this.setActiveTabByStatus();
              },
 
              onEntityInitialized: function() {
                this.callParent(arguments);
                this.setActiveTabByStatus();
              }
 
            }
		};
	}
);

как вариант добавить поле версии в продажу (просто поле), и сделать что бы кейс на это поле оринтировался при отображении (отображать кейс по этому полю справочному, кстати поле должно быть справочное)

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



Предположим, в разделе настроена первая версия кейса (далее DCMv1) с определенным набором активностей для каждой стадии.

По записи в разделе был запущен кейс и созданы новые активности согласно DCMv1.

Далее кейс изменен на вторую версию (далее DCMv2) с другим набором активностей.

В результате активности, которые были созданы по DCMv1, отвязываются от кейса и становятся обычными задачами, которые привязаны к сущности. Если перейти на другую стадию и обратно – к обычным задачам добавляются еще новые активности, согласно новому кейсу DCMv2.

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

Александр Тыра,

Условие запуска кейса уже занято.

Илья, если в ходе кейса только задачи, то да, все будет хорошо. А если в задачах запускается подпроцесс? То он скорее всего зависнет иди перейдет в состояние отменен. Риск только в процессах, которые запускается по шагам кейса.

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

У Вас при смене кейса процессы отменяются или зависают? Стандартно запущенные  процесы по кейсу отменяются при смене стадии в кейсе.

У нас зависло много процессов в статусе выполняется. Причина - кейс перешел в состояние отменен и удалил за собой все данные по запущенным процессам. Процессы зависли в статусе выполняется. А вот почему кейс отменился ни я, ни техподдержка не выявили.  Единственное в тот день переносили обновления, в том числе и кейса. Но эта версия не подходит по времени. Разница в 7 часов. в 13 часов ставились обновления. Кейс отменился в 20 часов.

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

Оба запустится одновременно.

Может на проде в пакете Custom есть замещенный объект Лид и там стоит другое значение по умолчанию для стадии лида? Либо какой-то процесс, который меняет стадию. 

А как создаются данные лиды? Если приходят из Landing page, то ещё в конфигурации Landing page могут указываться значения по умолчанию, в том числе для стадий

Alex Zaslavsky,

Нет, замещенного процесса нет. Процессы посторонние не запускаются, даже все базовые не активны (по лид-менеджменту)

Владимир Соколов,

Нет, создаются по процессу

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

Это может быть значение поля по умолчанию в дизайнере объекта «Лид» в одном из пакетов, в них же логика во встроенных БП на объекте «Лид», отдельные БП на событии создания или изменения лида, логика в событийном слое, триггер или значение по умолчанию в БД или, наконец, JS-логика на стороне карточки. Если создать тестовую запись на уровне ESQ (не сработает логика карточки) и на уровне Insert-запроса (сработает только логика БД), можно подтвердить или отсеять два последних варианта. Остальные нужно проверять, изучая все места вручную.

Попробуйте посмотреть логи приложения, есть ли там больше информации по ошибке?

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

В журнале они могут отображаться или нет в зависимости от его настроек. См. SysProcessLogSectionV2:

addHideDcmFilter: function(filters) {
	var filterName = "HideDcm";
	filters.removeByKey(filterName);
	var shouldHideDcm = !Terrasoft.isDebug && !this.getIsFeatureEnabled("ShowDcmInProcessLog");
	if (shouldHideDcm) {
		var managerName = Terrasoft.manager.DcmSchemaManager.managerName;
		filters.add(filterName, Terrasoft.createColumnFilterWithParameter(
			Terrasoft.ComparisonType.NOT_EQUAL, "SysSchema.ManagerName", managerName));
	}
},

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

В новых версиях обещают полноценный журнал кейсов.

Зверев Александр,

спасибо за ответ! Да, режим отладки включен. 

Александр, корректно ли, что этот процесс находится в статусе Running?