Comments 2
Достаточно стандартный вариант реализации, если честно. Делали такое лет 5 назад.(Столкнулись с тем, что кастомные скрипты долго работали и грузили систему). Расскажите кстати про обработку варианта, когда все согласовали, а кто один вернул вопрос на доработку.
Хорошо, что такой подход получает распространение. Нередко встречал концепцию, где «этап = статус»
Идея цикличного статуса у нас применялась еще до появления Insight. Тогда мы использовали плагин, позволявший задавать метаданные прямо в значения опций select-листа. Решение выходило полностью бесплатным: и Groovy был не от ScriptRunner, и сам кастомный select-лист тоже бесплатный. Минус был только в том, что конфиг приходилось сразу прописывать в JSON, что было неудобно при передаче управления заказчику. А основная цель всегда оставалась одна - минимизировать затраты на поддержку. Сейчас мы начали использовать assets. Переписали старые скрипты от чего и родилась идея для статьи. При этом проблем с производительностью такие реализации никогда не вызывали. Было бы интересно провести профилирование подобного кода.
Что касается вашего вопроса: если на каком-то этапе происходит отклонение, то задача возвращается из согласования инициатору. Он прорабатывает отказ и при необходимости запускает согласование заново. Для наших заказчиков этого было достаточно, хотя при желании логику можно сделать более сложной - но нам в этом просто не было необходимости
JIRA: Как мы сделали многоэтапное согласование в одном статусе (Groovy + Assets)