Доброго времени суток.

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

Заранее благодарен.

Нравится

3 комментария

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

 

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

Мотков Илья,

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

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

Показать все комментарии

Каким образом использовать функционал сервисных инженеров по сервису? 

В курсах указано:

1) Создать сервис и указать сервисных инженеров по уровню поддержки

2) В обращении указать сервис и уровень поддержки (по умолчанию указан 1 уровень), после чего в полях группа ответственных и ответственный должны быть доступны выбранные группы/ответственные. Но такого не происходит. Доступны все группы и все пользователи.

Нравится

3 комментария
Лучший ответ

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

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

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

 

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

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

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

Показать все комментарии

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

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

Прихожу к выводу, что при изменении группы ответственных надо знать еще и предыдущее значение группу. Если оно было пустое, то процесс не вызывать. Только вот как реализовать?

Нравится

1 комментарий
Лучший ответ

Добрый день.

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

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

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

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

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

Добрый день.

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

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

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

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

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

Показать все комментарии

Доброго времени суток.

 

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

Подскажите, пожалуйста, где это делается

Нравится

3 комментария
Лучший ответ

Добрый день!
Перейти в раздел обращений, из него в мастер раздела, далее вкладка "Портал" и нажать кнопку "Редактировать страницу".
А там уже добавлять, изменять поля

Добрый день!
Перейти в раздел обращений, из него в мастер раздела, далее вкладка "Портал" и нажать кнопку "Редактировать страницу".
А там уже добавлять, изменять поля

Спасибо. Кажется раньше этой вкладки не было? Еще в процессе разработки нашими кастомизаторами со страницы Обращения была убрана страница "Обработка", нет детали, где заказчик и обработчик заявки общаются. Точнее у заказчика она есть:

 

А у обработчика ее нет. Как можно ее вернуть?

Разверните на отдельном сервере вашу версию bpmonline и заберите оттуда все что вам нужно востановить....

Показать все комментарии

Здравствуйте, обнаружилось что несколько обращений доступны все пользователям портала (порядка 30 обращений), права выставлены стандартно, изменялось доступность бизнес процессом, который выдавал права только тем, у кого такой же контрагент, как в обращении. Переделал бизнес процесс на " при обновление любого поля, отбираются права у тех у кого не такой контрагент, и выдается тем у кого тот самый из обращения."

На новые обращения работает, но на эти 30 обращений не отбираются права. (Вижу обращения с контрагентом "Контрагент №2" через портал под пользователем с контрагентом "Контрагент №1" ) 

Вопрос, что может устанавливать права, кроме этого бизнес процесса? Техподдержка не помогла.

Нравится

4 комментария
Лучший ответ

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

Так мы исключим вариант, что процесс некорректный.

У наших клиентов тоже перераспределяются права на обращения после изменения SLA или Контакта, и всё срабатывает. Правда, там в условии я по старой привычке пишу, что Id должно быть заполнено, но возможно, сейчас такое и не требуется

Если процесс даже не запускается на редактирование полей, то покажите стартовые сигналы

Владимир Соколов, запускается, на каждое изменение, но не отрабатывает, как будто права, кто-то свыше меняет.

 

Rinat,

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

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

Также, возможно, отрабатывает еще какая-то дополнительная логика. Чтобы понять, что это может быть, посмотрите SQL Profiler, какие запросы идут в этот момент в базу данных.

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

Так мы исключим вариант, что процесс некорректный.

У наших клиентов тоже перераспределяются права на обращения после изменения SLA или Контакта, и всё срабатывает. Правда, там в условии я по старой привычке пишу, что Id должно быть заполнено, но возможно, сейчас такое и не требуется

Показать все комментарии

Здравствуйте, при доработке добавили несколько новых состояний обращения. Одно из них это "Проведен расчет", суть практически такая же как и у "Закрыто".

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

Каким образом модифицировать эту галку, чтобы она цепляла за собой и обращения с новым состоянием "Проведен расчет"?

Нравится

3 комментария
Лучший ответ

Либо у нового статуса проставить галочку IsFinal. Тогда изменять код не придется

Добрый день!
Необходимо заместить схему CaseSection и модифицировать метод getFilters

Либо у нового статуса проставить галочку IsFinal. Тогда изменять код не придется

Сидоров Александр В., Спасибо большое, надо было документацию мне повнимательней читать)

Показать все комментарии

Ситуация по шагам: 

1. Клиент пишет обращение 

2. Ему приходит оповещение (Ваше обращение зарегистрировано т.д.) 

3. Клиент отвечает на это оповещение что-либо. 

4. В системе создается новое обращение 

5. Клиенту приходит еще одно оповещение соответственно. 

 

Разворачивал демостенд, насколько понимаю это является стандартной логикой BPM. 

Вопрос:

Можно ли избежать такой ситуации? Как сделать так, что бы при ответе на оповещение не создавалась новое обращение? 

Нравится

1 комментарий

Новые письма привязываются к существующим инцидентам, если в их тексте есть упоминания номера, например №SR-12345.Значит, нужно в автоматическом шаблоне или в ручном ответе указывать номер в таком формате. Тогда при ответе будет не создаваться новое, а переоткрываться старое. Формат задаётся в системной настройке «Маска номера обращения». 

Показать все комментарии

Добрый день!

Столкнулись с следующей ситуацией: для портальных пользователей не отображается на детали История email отправленные ими же. 

Кейс: cпочты пользователя портала отправляется письмо на почту техподдержки, это письмо регистрируется в системе (активность с типом email), по нему создается обращение в системе со связью с письмом. Можно добавить портальное сообщение. Со стороны бэкофиса на странице Обращения на детали История первой записью будет отображаться письмо от пользователя. Если зайти со стороны портала, то данного письма на детали не будет.

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

Спасибо! 

Нравится

6 комментариев

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

Мы реализовывали раздачу прав пользователям портала на записи в БП. 

Ключевое здесь - это выдача прав на Activity по полученному письму. 
И основная сложность - это отловить получение письма. Примерно так выглядит сигнал на это событие:

Владмир, спасибо за информацию. Жалко, что на скриншоте ничего не видно. Можно сделать дололнение для маркета.

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

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

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

Владимир, подскажите, пожалуйста, как именно происходила раздача прав (настройка элемента процесса)? Требуется ли дополнительная настройка прав в разделе Администрирования: Доступ к объектам?

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

Показать все комментарии

Добрый день, Коллеги!
Возникла потребность в настройке итога для обращений (тип показатель) для вычисления "средней скорости закрытия обращения".

Необходимо для объекта "Жизненный цикл обращения" по колонке "Продолжительность часов" высчитать среднее значение времени, а именно "как быстро обращение перешло из состояния Новое на одну из завершающих стадий (включая время нахождения на промежуточных этапах по отдельности) Закрыто или Отменено".

Вопрос в следующем:
Возможно ли настроить фильтрацию таким образом, что бы захватывать общую, среднюю продолжительность времени для всех обращений, по всем состояниям кроме "Закрыт" (т.к. в базе в колонке EndDate всегда будет NULL для стадии закрыт)?

Аналогичная вопрос о настройке фильтрации возникает с записями в объекте CaseLifecycle для случая, когда Новое обращение было взято "В работу", а затем "Отменено", так как в базе будет существовать три записи, но для конечной стадии Отменено EndDate = NULL.

Как именно в таком случае будет вычисляться среднее значение по нескольким записям CaseLifecycle и Case, если EndDate = NULL? Будет ли прибавляться просто 0 часов и учитываться в количестве записей жизненного цикла при расчёте среднего?

Возможно кто-то уже сталкивался с подобной задачей.
На скриншоте приведена попытка настройки итога.
Заранее спасибо!

Нравится

5 комментариев

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

Базовыми средствами системы реализовать задачу можно, но нужно немного новых объектов и SQL запросов.

Построенная аналитика не совсем корректна - она отображает среднее время нахождения обращения на какой-то из стадий (то есть, отображается среднее значение, но не требуемое).

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

  1. Обращение (справочное с ссылкой на объект "Обращение") - с названием Case
  2. Суммарное время обработки (целое число) - с названием TotalSolution

В свойствах объекта укажите признак "Представление в БД"
3) Опубликуйте объект
4) Создайте представление в БД запросом:

create view UsrMyVwObject
as
select NEWID() "Id", c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id "CaseId", sum(StateDurationInMinutes) "TotalSolution"
from "Case" c
join CaseLifecycle
on CaseLifecycle.CaseId = c.Id
group by Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id

5) Стройте аналитику по созданному объекту - необходимо посчитать среднее значение по полю TotalSolution.
В фильтре аналитики необходимо указать условие, что учитываются только обращения в конечном состоянии, так как незавершенные обращения не должны влиять на построение статистики.

P.S. SQL запрос не проверял - рекомендую самостоятельно проработать его.

Алексей, ещё раз добрый день!
Спасибо огромное за комментарий, попробовали реализовать.
Создали объект UsrAverageCloseSpeed
И две колонки
UsrTotalSolution - дробное число
UsrCase - справочное поле с ссылкой на обращение.
Возникли трудности именно с созданием представления в БД. Попробовали доработать согласно вашим рекомендациям SQL мкрипт, но проверка заканчивается с ошибкой Ambiguous column name "Id"

CREATE VIEW UsrAverageCloseSpeed
AS
SELECT NEWID() Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id, sum(clc.StateDurationInMinutes)
FROM [ofd_dev].[dbo].[Case] c
JOIN [ofd_dev].[dbo].[CaseLifecycle] clc
ON clc.CaseId = c.Id
GROUP BY Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id

Просим помочь разобраться или детальнее объяснить структуру SQL создания представления БД.
Заранее спасибо!

UPDATE
Перечитал я что написал с вечера, немного исправлю(кстати, первые два пункта были в изначальном запросе).
1) как правильно указал коллега ниже, нельзя создать 2 колонки с Id, c.Id AS CaseId вполне сработает.
2) нельзя также оставить последнюю колонку без имени, так как это view, нужно сделать примерно так:
SUM(clc.StateDurationInMinutes) AS TotalSolution
3) GROUP BY Id сделать точно не получится, так как GROUP BY еще об этом алиасе ничего не знает, фактически, еще даже newid() в этот момент не отработала, его нужно просто убрать.
Итого:

CREATE VIEW UsrAverageCloseSpeed
AS
SELECT NEWID() AS Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id AS CaseId, SUM(clc.StateDurationInMinutes) AS TotalSolution
FROM [Case] c
JOIN CaseLifecycle clc
ON clc.CaseId = c.Id
GROUP BY c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id

Вот такой запрос на моей базе успешно отработал.
P.S. Рекомендую Case взять в квадратны скобки, так это еще и зарезервированное слово в SQL.

"Титаев Александр Николаевич" написал:Просим помочь разобраться или детальнее объяснить структуру SQL создания представления БД.
Заранее спасибо!

Ну логично, вы пытаетесь создать вью с двумя одноименными колонками, что ваша первая Id что c.Id в результирующем запросе будут называтся Id. Так нельзя. Можно вроде этого:

CREATE VIEW UsrAverageCloseSpeed
AS
SELECT NEWID() Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id as UsrCaseId, sum(clc.StateDurationInMinutes)
FROM [ofd_dev].[dbo].[Case] c
JOIN [ofd_dev].[dbo].[CaseLifecycle] clc
ON clc.CaseId = c.Id
GROUP BY Id, c.CreatedOn, c.CreatedById, c.ModifiedOn, c.ModifiedById, c.Id

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

upd, так же упустил пункты 2.3. описанные выше Ильей, почитайте их ;)

Коллеги, спасибо большое за оказанную помощь!
Разобрались и дополнили)

Показать все комментарии

Коллеги, добрый день!
Хочу упорядочить состояния обращений на кнопке https://yadi.sk/i/gHMZhZ-f3GwETh, чтобы первым было состояние "Взять в работу". Как я поняла, все настраивается в справочнике Состояния обращений. Состояние "Отклонено по SLA" является конечным, последующие стадии не указываются. Для состояния "В работе" указаны последующие стадии https://yadi.sk/i/vTu9Wxf23GwHSs Результата нет.
Как правильно выполнить сортировку данной кнопки?

Нравится

1 комментарий

Добрый день, Елена!

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

Показать все комментарии