Добрый день!

Запрос "SysModuleVisa" в этом разделе показывал, что у Вас было настроено визирование в разделе с обращениями, но схемы для этой визы в БД не существовало.

select * from "SysModule"

where "SysModuleEntityId" in (

select "Id" from "SysModuleEntity" where "SysEntitySchemaUId" in (

select "UId" from "SysSchema" where "Name" = 'Case'))



select * from "SysModuleEdit"

where "SysModuleEntityId" = '6513d6fc-9383-4bfb-8e0b-a6dc8e7231b0'



select * from "SysModuleVisa" where "Id" = '2e41b591-9f9f-4b80-9aa4-6bcf8d5cdd5e'

select * from "SysSchema" where "UId" = '9b657b4f-80dc-475d-92f1-0f5633d73cd5'

последний запрос ничего не возвращает, то есть у вас настроено визирование в разделе с обращениями, но схемы визы не существует

update "SysModule"

set "SysModuleVisaId" = null

where "SysModuleEntityId" in (

select "Id" from "SysModuleEntity" where "SysEntitySchemaUId" in (

select "UId" from "SysSchema" where "Name" = 'Case'))



delete from "SysModuleVisa" where "Id" = '2e41b591-9f9f-4b80-9aa4-6bcf8d5cdd5e'

Мы обновили "SysModule" и удалили в "SysModuleVisa" упоминание о визировании этого раздела в БД.

На данный момент, Мастер раздела успешно сохраняет изменения.

Добрый день, 

Просим написать на support@terrasoft.ua для более детального анализа вопроса. 

С уважением, 

Игорь

Видимо проблема с правами. У пользователя нет прав на второе письмо, которое он не видит.

Ну а почему - причин у этого может быть ОООчень много.

Создаю новое поле - Reminding time. И его сравниваю.

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

Александра Дубс, подскажите, решило ли вашу задачу предоставленное решение от Владимира?

Aleksei Efimenko, 

я прибегла к другому решению:

• сделала системную настройку, которая хранит значение за сколько нужно уведомление (в минутах)
• сделала 2 параметра: 

Параметр 1: [#Системная переменная.Текущее значение времени#]. AddMinutes([число из системной настройки])

Параметр 2: параметр 1. AddMinutes(59) - чтобы получился час

• и развела условными потоками:

1. если время разрешение больше моих параметров или меньше - проскакиваю

2. если время разрешение попадает в промежуток параметров - высылаю уведомление

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

В базовом функционале приложения нет возможности разрешить портальным пользователям изменять стадии обращения на 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);
},

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

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

Думаю, заказчику лучше обратиться с вопросом к тому, кто разрабатывал сценарий. Без подробностей сложно сказать, что именно он делает в системе. Например, если каждый раз сохранять запись о новом обращении с одним и тем же Id (а при нормальной работе он уже есть в запросе к /0/DataService/json/SyncReply/InsertQuery), то не создастся много записей, а будут ошибки.

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

Но учтите, что на это поле завязано много логики, как специфичной для раздела обращений, так и общей для всех разделов (например, выдача ответственному прав доступа). Всю её потребуется адаптировать под разработанную функциональность.

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

спасибо

Альмир, можно попробовать реализовать это бизнес-процессом:

Сначала создаём в контакте (или контрагенте, если привязка будет ним) новое поле «Агент КЦ» (или используем для этой цели стандартное поле «Ответственный»).

Затем создаём БП, срабатывающий при создании обращения. Проверяем в нём значение поля «Контакт» и по ссылке «Агент КЦ» этого контакта. Если там заполнено, распределяем обращение на него, выставляя в нём поле «Ответственный». А если пусто, то есть контакт ничейный, то распределяем на того, у кого меньше других обращений, то есть выставляем его в «Ответственный» в обращении и «Агент КЦ» в контакте.

Видеть только свои записи можно при помощи раздачи прав доступа только ответственному. В БП есть специальный элемент для работы с ними. См. пример работы с ним тут.

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

Здравствуйте, Кирилл!

Ваш вопрос по нескольким DCM в зависимости от типа записи? Если да, то это настраивается в дизайнере и работает в новых (созданных мастером) разделах. В CasePage тоже по идее должно. Если вопрос как сделать разные наборы для портала и системы – никак. DCM один и он общий для обоих пользователей. Пользователь на портале видит те же шаги, что и пользователь системы. А тип выбирается в зависимости от записи и тоже не зависит от типа пользователя.

Мотков Илья,

Да, по нескольким DCM. В разделе Case  в мастере настроил несколько progressbar в зависимости от значения поля. Для системных пользователей всё работает. Но для портальных пользователей не работает. Отображается progressbar по умолчанию при любом значении указанного поля. Разные наборы для портала и системы мне не нужно делать

Походу проблема, возможно, из-за кастомной разработки. Развернул чистую версию 7.14.3 и там всё корректно работает.

А стрелка вниз в этом поле ещё работает? Кажется, ею можно было вызвать отфильтрованный список

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

Константин Марков,

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

Добрый день.

Если хотите сравнивать значения до и после, то есть 2 варианта.

1. Запускать процесс не по сигналу, а из клиентских скриптов, например, из карточки редактирования обращения.

2. Реализовать данную логику через событийные процессы схемы таблицы на серверной стороне.

И в одном, и в другом случае есть возможность сравнить значение до изменения и после.

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