Use transitions in JQL to filter issues?

[Jens]

Hello, 

i like to build a customized dashboard for our developers and testers that shows all assigned issues broken down into separate lists based on issue status or the next step to do. 

The goal is to help the developers and testers easily spot and distinguish the importants of issues. Currently we aim for this issue lists: showstopper, duedate, "analyse / estimate", high priority

For that we use the filter results widget with currentUser() JQL-filters. 

Our current problem is that we don't have a dedicated status for "analyse / estimate" in our Standard Workflow only the transition:estimate. And as we try to keep our workflow to the bare minimum, we really like to keep it that way.

Our Workflow (simplified):

status:open > [...] > transition:estimate > status:estimated > transition:authorize > status: authorized > transition: develop > status:"in development" > transistion:solve > status:solved > transition:test > status:"in Test" > transition:accept > status:accepted > transition:merge > status:merged > transition:deploy > status:deployed > [...] > status:done > [...] > status:closed

So is there a way to use JQL to query for issues that have the valid transition: "analyse / estimate" for their current status and for the current user?

If you have thoughts to share or questions to ask. Let's hear it! :) 

Cheers

Jens

[Nic Brough -Adaptavist- · Accepted solution]

You can't do this as described - a transition is an action, not a piece of data.  Issues do not "have a transition", they undergo them when a person asks for them.

Transitions are enabled via the workflow and may have conditions.  This means that not only is it hard to extract a transition, it can change dependent on the data and user who is looking, making the idea pretty much useless for reporting even if you could do it.

You should be looking to the current status and the data on the issue that is telling you that it needs the analysis/estimate doing.

[Jens]

Hey Nic, 

Issues do not "have a transition", they undergo them when a person asks for them.

Yes, i suspected that much, my hope was that it is possible to query for transitions from looking at the issue status combined with currentUser.

Transitions are enabled via the workflow and may have conditions.  This means that not only is it hard to extract a transition, it can change dependent on the data and user who is looking, making the idea pretty much useless for reporting even if you could do it.

Well, i don't agree on that, as we want to emphasize todos. And in the way we use the jira workflow the transitions are exactly that.

In contrast the current issue status tells us where the issue stands right now like 'in development' or 'done'.  

You should be looking to the current status and the data on the issue that is telling you that it needs the analysis/estimate doing.

Currently we write a comment to tell a developer to analyse / estimate an issue. And i didn't consider querying comments. Let alone we had to maintain a strict code for writing this comments to be queryable... And after the developer did his part we have to remove the comment, ... doesn't sound robust or easy.

Can you please elaborate on '...the data on the issue that is telling you that it needs the analysis/estimate doing.'.

[Nic Brough -Adaptavist-]

So the transitions are conditional, so they're not of any real use for reporting in the way that you want. 

You need to be looking at status, not transition.

Maybe you should be looking to put the "analyse/estimate" request into the workflow explicitly?  Have a transition into "needs analysis", then your developer can move it on when they've done that.  Far easier than comments (especially if you don't bother them with any extra fields, a simple status change is the request, and another when it's done)

That is what I meant by "the data on the issue that is telling you that it needs the analysis/estimate doing" - there's something on the issue telling people something needs doing.  I'd do it with status probably, but you could use flag fields instead.

[Jens]

thx for the clarification.