All streams
Search
Write a publication
Pull to refresh

Comments 2

Достаточно стандартный вариант реализации, если честно. Делали такое лет 5 назад.(Столкнулись с тем, что кастомные скрипты долго работали и грузили систему). Расскажите кстати про обработку варианта, когда все согласовали, а кто один вернул вопрос на доработку.

Хорошо, что такой подход получает распространение. Нередко встречал концепцию, где «этап = статус»

Идея цикличного статуса у нас применялась еще до появления Insight. Тогда мы использовали плагин, позволявший задавать метаданные прямо в значения опций select-листа. Решение выходило полностью бесплатным: и Groovy был не от ScriptRunner, и сам кастомный select-лист тоже бесплатный. Минус был только в том, что конфиг приходилось сразу прописывать в JSON, что было неудобно при передаче управления заказчику. А основная цель всегда оставалась одна - минимизировать затраты на поддержку. Сейчас мы начали использовать assets. Переписали старые скрипты от чего и родилась идея для статьи. При этом проблем с производительностью такие реализации никогда не вызывали. Было бы интересно провести профилирование подобного кода.

Что касается вашего вопроса: если на каком-то этапе происходит отклонение, то задача возвращается из согласования инициатору. Он прорабатывает отказ и при необходимости запускает согласование заново. Для наших заказчиков этого было достаточно, хотя при желании логику можно сделать более сложной - но нам в этом просто не было необходимости

Sign up to leave a comment.

Articles