АШ
А если в постфункциях куча изменений полей после смены статуса?)
Size: a a a
2021 May 26
КТ
А что с этим не так?
АШ
Насколько я понимаю, история измнений это что-то лога, и нет гарантий что изменение статуса будет условной "последней строчкой" в изменениях
КТ
Так и не надо обязательно последней
АШ
Если в постфункциях переходов допустим пачка изменений полей
PA
В этом есть смысл, если вешать логику на Listener
КТ
История - это объект с массивом изменных полей, среди которых есть поле status
PA
так ка кон вызывается на каждое изменение отдельно
КТ
А в постфункциях есть такая системная функция - Update change history for an issue and store the issue in the database. - которая и формирует запись в историю
it
только вот если я правильно помню, событие "issue updated" на изменение статуса не дергается, там как раз generic event по умолчанию тригерится
PA
если меняешь руками статус - то Issue Update
но можно статус через API дёргнуть - Generic Update
но можно статус через API дёргнуть - Generic Update
it
что такое "меняешь руками статус"?
PA
кнопку нажал с названием статуса
it
и чем это отличается от "статус через API дёргнуть"?
PA
кнопка может быть зациклена на однои и том же статусе, и при её нажатии можно перевести в любой статус, а можно ничего не делать, тогда статус по сути не меняется
КТ
Меняется сам в себя
it
если честно, я ничего не понял
КТ
private ChangeItemBean findChangeStatusBean(ChangeHistory history) {
for (ChangeItemBean item : history.getChangeItemBeans()) {
String field = item.getField();
if (field.equals("status")) {
return item;
}
}
return null;
}Вот пример поиска статуса в истории
PA
да, но это "идеологически" не смена статуса :)
it
но суть в том, что при "переходе" задачи не срабатывает событие "issue updated", оно срабатывает при редактировании (неважно, руками, через апи или скриптом)
при переходе срабатывает ровно то событие, которое указано в постфункциях
при переходе срабатывает ровно то событие, которое указано в постфункциях