Добрый день!

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

А там уже добавлять, изменять поля

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

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

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

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

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

Rinat,

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

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

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

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



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



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

Добрый день!

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

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

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

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

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

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

Ключевое здесь - это выдача прав на Activity по полученному письму. 

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

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

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

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

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

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

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

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

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

Базовыми средствами системы реализовать задачу можно, но нужно немного новых объектов и 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. описанные выше Ильей, почитайте их ;)

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

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

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

Добрый день, Александр!
В базовой версии продукта функционал визирования обращений будет реализован. О сроках реализации сообщить сложно, сейчас подготавливается релиз 7.9, в который данный функционал еще не входит.

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

Если Вас интересуют возможности реализации функционала с нашей помощью, Вы можете связаться с Вашим менеджером для согласования всех вопросов.
Хорошего Вам дня!

Пускай другие пользователи почистят кеш браузера и перезайдут на сайт ;)

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

Добрый день. Подскажите, вы сделали подкраску реестра, даже если данные колонки не выведены в реестр?

Добрый день.
У меня колонки выведены, далее не делала.

Для того, чтобы значение колонки подгружалось, даже если оно не выведено в раздел, необходимо:

1) Заместить схему секции.
2) Переопределить метод initQueryColumns.
3) В замещающем методе в параметр esq добавлять нужную колонкую

Пример:

initQueryColumns: function(esq) {
	this.callParent(arguments);
        // проверка на присутствие необходимой колонки в esq
	entitySchemaQuery.addColumn("имя колонки");
},