Size: a a a

Camunda BPM Group

2020 March 24

С

Сергей in Camunda BPM Group
Мне вообще кажется, что в работе и ожидание это не статусы жизненого цикла задания. Это признак ведется ли в данный момент по нему работа. Надеюсь понятно выразился
источник

AK

Artem Kuraev in Camunda BPM Group
Ну почему же? Жц такой: создана -> в ожидании -> взята в работу -> снята с человека -> взята в работу -> сделана
источник

DG

Dmitrii Goncharov in Camunda BPM Group
Artem Kuraev
Ну почему же? Жц такой: создана -> в ожидании -> взята в работу -> снята с человека -> взята в работу -> сделана
+, я тоже считаю, что это и есть лайфцикл задачи
источник

С

Сергей in Camunda BPM Group
Ожидание это странный статус
источник

С

Сергей in Camunda BPM Group
Чем он отличается от назначено
источник

AK

Artem Kuraev in Camunda BPM Group
А, я вас понял
источник

AK

Artem Kuraev in Camunda BPM Group
Если по бизнес-процессу задача не на группу распределяется, а непосредственно на пользователей, то тогда действительно граница между ожиданием взятия в работу и непосредственно работой размыта
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
Dmitrii Goncharov
Мы на своем фронте делали по assignee и candidate. В соответствии с ними отображали
У нас candidate -> assignee -> executor )
источник

AK

Artem Kuraev in Camunda BPM Group
Может, тогда правильнее было бы использовать Candidate Users для назначения задачи и assignee для контроля фактической работы над задачей
источник

AK

Artem Kuraev in Camunda BPM Group
Тогда действительно можно отслеживать, сколько задача ожидала, что её возьмут в работу и сколько над ней велась работа
источник

DG

Dmitrii Goncharov in Camunda BPM Group
В общем отталкиваться нужно от вашего видения статусов, но суть таже -  assignee, candidateUser и candidateGroup, их заполненность служит показателем статуса жертвовать тут ничем не нужно, равно как и добавлять какие-то новые поля к DTO задачи
источник

AK

Artem Kuraev in Camunda BPM Group
Dmitrii Goncharov
В общем отталкиваться нужно от вашего видения статусов, но суть таже -  assignee, candidateUser и candidateGroup, их заполненность служит показателем статуса жертвовать тут ничем не нужно, равно как и добавлять какие-то новые поля к DTO задачи
👍
источник

С

Сергей in Camunda BPM Group
Artem Kuraev
Тогда действительно можно отслеживать, сколько задача ожидала, что её возьмут в работу и сколько над ней велась работа
Кажется я понял для своей задачи. Для меня взятие в работу это как запустить секундомер, ожидание, остановить его. Я не буду вкрячивать это в статусы камунды, а реализую отдельно
источник

AK

Artem Kuraev in Camunda BPM Group
Сергей
Кажется я понял для своей задачи. Для меня взятие в работу это как запустить секундомер, ожидание, остановить его. Я не буду вкрячивать это в статусы камунды, а реализую отдельно
По хорошему, сбор информации о временах нахождения задач в процессах на разных этапах их жизненного цикла, это задача процессного движка
источник

С

Сергей in Camunda BPM Group
Artem Kuraev
По хорошему, сбор информации о временах нахождения задач в процессах на разных этапах их жизненного цикла, это задача процессного движка
А она реализована в камунде? Я пытался найти, возможно приложил мало усилий
источник

AK

Artem Kuraev in Camunda BPM Group
Сергей
А она реализована в камунде? Я пытался найти, возможно приложил мало усилий
Да, в истории видно
источник

С

Сергей in Camunda BPM Group
act_hi_taskinst эта табличка?
источник

С

Сергей in Camunda BPM Group
Хотя не похоже
источник

С

Сергей in Camunda BPM Group
act_hi_detail похоже она
источник

AK

Artem Kuraev in Camunda BPM Group
В энтерпрайз кокпите это выглядит так:
источник