nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

how to capture date/time & field data during repetitive transitions

rjzorn

I have a workflow that includes a "build - test - rebuild" loop possible, and I would like to capture date/time and tag/comment field data for each iteration without losing historical loops. This would be used in the future reporting, by being able to report that a product was "rebuilt" 12 times, over X number of days, with 7 different tags, etc. The issue I am having now is that when you transition back to the "rebuild" status, the date stamp is overwritten, rather than concatenated.

Accepted answers

Tom Lister_fo1j4e

Hi @rjzorn

All workflow status changes will be recorded in the issue change history and can be viewed in the activity history tab

Screenshot 2022-05-11 at 16.39.43.png

How are you thinking of using the data? There are tools such as eazyBI that can analyse issue history.

Craig Nodwell_7eve9b

Hi @rjzorn short of building out a lot of things that you would then have to maintain ex: you could build out rest calls to get the changlog and then wrap python or javascript around the results, or purchasing a plugin to make this easy on you for query and reporting ex: Time In Status. What you could do it create a field that you place on no screens, that you can write your details into on a post function giving you the ability to update rather than overwrite. You can include this field in your list columns and export out to reports. If you have scriptrunner you can get very creative using this technique.

All comments

Tom Lister_fo1j4e

Hi @rjzorn

All workflow status changes will be recorded in the issue change history and can be viewed in the activity history tab

Screenshot 2022-05-11 at 16.39.43.png

How are you thinking of using the data? There are tools such as eazyBI that can analyse issue history.

Craig Nodwell_7eve9b

rjzorn

Craig,

I agree with everything you said, and I think the idea of creating a hidden field that I just add data to each time, sounds like it would suffice, and then it will just come down to extracting the information for a report. I had not even thought about a field that was not present on any screens, so thank you so much for clearing my blind spot.

I appreciate your input,

Thank you

RoN

rjzorn

Tom,

I was thinking that having a quick way to view the number of times it went into rebuild would be useful, but you are right, I could just create a quick counter, and then use the history to gather the specifics for a report

RoN

Craig Nodwell_7eve9b

You're welcome. Glad to help.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server