Hi all,
for process verification purposes, I need to extract information on existing JIRA issues from our JIRA installation... In particular, I need to know who executed which transaction hsa been executed when by whom for a particular issue (ideally: for a particular set of issues). I need not only "Status A -> Status B" as shown by Jira Suite in the "Transitions" tab, but more like which button was klicked by which user and when; also - if a transition has bene executed several times, then JSU does not show all of the executions but only the last one...
Any ideas?
Many thanks in advance
Best regards
Dmitri
It's in the issue history tab - you need to look for each change of status (The jira suite utilities is just summarising information it's pulling from there)
There's no way of knowing what "button was clicked" though - there are many ways of triggering a transition and how they are triggered is completely irrelevant, it's the fact that the person logged as doing it was granted permission to do so by your security settings that matters.
Hi Nic,
is there any way to query the contents of the history tab via SQL? We need it for quite a bunch of issues, and navigating to each individual issue seems a bit cumbersome...
Regarding "Button pressed": the "button pressed" is actually the transition's name. Is there anyway to find out that particular name?
There might be several transitions from one step to another, therefore knowing the start and end of a transition is typically not sufficient...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Absolutely, although it's better presented in the history tab.
I'm not sure what the best angle for your needs are, so I'll explain how I'd do it for a single issue, just to explain the relationship.
You need to look at three tables. Jiraissue contains the issue, most importantly, the unique and immutable issue-id. You can read changegroup, which is the list of changes made to an issue by the time they were made. You'll find each line has a unique ID, then the issued-id, and then you'll be interested in the date, time and author of the change. Finally, you take the changegroup.id and use that to select the groupid from changeitem. Changeitem lists each separate change that was made to the issue during that edit or transition. So you'll find reading changeitem for "status changed from xxx to yyy" is the eventual answer.
The "button pressed" is harder and easier. What I was getting at was that it's not always a button - it could be a drag and drop on an Agile board, an update by a listener, a REST call from the outside, etc. But it will always be a transistion. Problem is the transition is not recorded, just the change of status - this is because workflows can change, and actually, the transition is still not important. It's the "to status, from status, who and when" you really want. If you've got several transitions doing the same change, I'm afraid you're stuck - that's simply not recorded (and you can't because if I edit a workflow, I could easily remove or change a transition)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nic,
basically you are right and what I need is the transition name.
And this is why I need it (and not only who/when/from where to where):
In our workflow, we have a status called... Let's say "Waiting for approval". Now there are two different transitions going from this state to the "approved" state: one is the normal "Approve" and the other one is "Emergency approve" - both of them have different conditions (i.e., "Emergency approve" can be pulled off by a wider group of people) and both have different post-functions ("Emergency" sets some flags, which trigger an "Emergency review" in the later process).
With this being said, for audit purposes, I need to be able to tell "Emergency approve" from "Approve"...
Does this make sense to you?
Many thanks in advance
Best regards
Dmitri
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, and you've almost answered it yourself.
You mention that your transitions set different flags - you can use those to detect/infer what transition was used. You could easily use another custom field to store it as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sounds like a nightmare for reporting...
"I will think about it tomorrow" - (c) Scarlett O'Hara
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.