TrackStudio Forum

[babay]

у меня есть потребность в следующих возможностях
1) автозаполнение тех или иных полей при смене статуса. с вычислением. (например, чтобы вычислилось время, проведенное в статусе и добавилось уже к полю - оценка времени фикса и теста бага)
2) _важно_ занесение имени текущего пользователя в определенные поля при смене статуса (кто пофиксил баг, кто поресолвил, возможно при ручной выливке - кто вылил итд)
3) автозанесение ранее сохраненного пользователя в "assigned to" при смене статуса (с возможностью редактирования) - например, для того, чтобы после фикса бага автоматически ассигнился на правильного тестера.
4) смена статуса списка багов (по фильтру поиска) по определенному внешнему ивенту - например, при билде с помощью TeamCity все баги из статуса fixed переходили в fixed-builded и назначались на тестера - после чего их можно тестировать.

и если тох или иной возможности нет - насколько сложно её дописать самостоятельно на скриптах ?

[admin]

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

Это можно сделать Add Message / AFTER скриптом, но лучше использовать стандартный UserWorkload report, из него эти данные можно получить.

2) _важно_ занесение имени текущего пользователя в определенные поля при смене статуса (кто пофиксил баг, кто поресолвил, возможно при ручной выливке - кто вылил итд)

Да, тоже можно скриптом, а зачем это нужно, если не секрет ? Если нужен поиск всех задач, которые пофиксил X, то можно делать поиск задач с фильтрацией по сообщениям.

3) автозанесение ранее сохраненного пользователя в "assigned to" при смене статуса (с возможностью редактирования) - например, для того, чтобы после фикса бага автоматически ассигнился на правильного тестера.

Тут можно задать список возможных Handler-ов через настройку прав для message type и дополнительно контролировать через скрипт
http://www.trackstudio.com/forum/bug-tr ... -1036.html

4) смена статуса списка багов (по фильтру поиска) по определенному внешнему ивенту - например, при билде с помощью TeamCity все баги из статуса fixed переходили в fixed-builded и назначались на тестера - после чего их можно тестировать.

Думаю, тут лучше всего подойдет внешнее приложение, которое бы запускалось при событии, коннектилось бы к TrackStudio, получало бы список задач и добавляло бы им правильный Message.

Из Вашего списка наиболее криво реализуется пункт (3), т.к. задавать список Handler-ов скриптом нельзя, а можно только по-разному реагировать на выбор пользователя. Все остальное - вполне штатно.
-

[babay]

2) _важно_ занесение имени текущего пользователя в определенные поля при смене статуса (кто пофиксил баг, кто поресолвил, возможно при ручной выливке - кто вылил итд)

Да, тоже можно скриптом, а зачем это нужно, если не секрет ?
-

идея проста: на пути жизни бага в специальных полях запоминаются а) человек, законфирмивший баг (тестер, который завел или который поджтвердил баг от конечного пользователя), б) программист, пофиксивший баг.
после фикса бага он переводится в состояние "пофиксено" и автоматически при смене состояния (пункт 3 моего изначального вопроса) владельцем бага становится тестер, его подтвердивший.
то же самое, при возврате бага BackToFixing, автоматически владельцем бага становится программист, его фиксивший.
всё это для уменьшения временных затрат на работу с багами.
да, конечно, можно возразить, что а если человек в отпуске (или уволился) а баг срочен - ну что ж, так бывает существенно реже. тут требуется вмешательства манагера. чтобы отобрать баг и раздать как надо.
идеальным решением, конечно, был бы статус пользователя типа "временно недоступен" - в результате чего при ассигне на него бага манагеру приходит письмо. но это уже существенно менее важно.

[admin]

Тогда будет оптимально разрешить в настройках message type permissions быть handler-ом всем, а правильного handler-а принудительно выставлять триггером во всех случаях.

Кстати, запоминать в кастом-поле не обязательно, скрипт вполне может анализировать историю сообщений и определять кто в последний раз закрывал/ресолвил задачу оттуда.

[babay]

Кстати, запоминать в кастом-поле не обязательно, скрипт вполне может анализировать историю сообщений и определять кто в последний раз закрывал/ресолвил задачу оттуда.

да, скрипт может.
но всё же уютнее - открываешь баг - и знаешь, кто его фиксер, кто его тестер... ) )

[mvasenkov]

Кстати, запоминать в кастом-поле не обязательно, скрипт вполне может анализировать историю сообщений и определять кто в последний раз закрывал/ресолвил задачу оттуда.

да, скрипт может.
но всё же уютнее - открываешь баг - и знаешь, кто его фиксер, кто его тестер... ) )

Максим имел ввиду вычисляемые поля. Результат на экране будет практически тем же, что и после выполения триггеров, но в работе разница есть: вычисляемые поля пересчитываются либо при каждом обращении, либо, если стоит галка "кешировать" - при изменении задачи (добавлении сообщения, аттачмента и т.п.). При этом пользователю поле для ввода значений этих полей не выдается. В случае же триггеров пользователю будет доступно поле ввода, но зато привязка к событию будет более явной. Однако тут нужно учитывать, что триггер выполяется каждый раз при наступлении такого события, а не только в первый раз (если нужно учитывать время первого resolve задачи, а не последнего, нужно будет проверять на заполненность поля, например).