JQL to list issues converted from subtasks

[David Moore]

I am looking to get a list of issues ("Bug" in this case) that have been converted from sub-tasks (using the "Convert to Issue" option in the ... menu in the subtask)...

Tried the obvious (Parent / ParentLink / IssueType) but none of the "historical" (was / changed from / changed to) operators seem to be available...

Any thoughts? We can work around it, but it seemed to me to be something that should be available out of the box...

Thanks!

[Ste Wright · Accepted solution]

Hi @David Moore 

Not natively. You'd need a CHANGED function for Issue Type.

There might be an app which can assist with this on the Marketplace, which has an appropriate advanced JQL function. It's not something I've personally seen for Cloud though!

An alternative is to use CHANGED with Status if the workflows differ between Sub-Task and a Standard Issue Type. If a status is unique to Sub-Tasks then you can search for issues that were in that status and now are not :)

------------------

There is another alternative I just thought of, using Automation:

1. Create a custom field, for example a "Select List (single choice)" - with the options Yes and No. Name the field "Sub-Task"
2. Add an Automation Rule. Use the Trigger "Create Issue" and add a Condition, which checks if the issue type is Sub-Task. Add an Action to set the custom field to "Yes"

^ This means at creation Sub-Tasks will have the field set. You'd need to do a bulk edit to correct existing Sub-Tasks.

Then, post-conversion you could search for any issue in a standard issue type, which has the custom field set to "Yes". Keep the custom field off all screens so it's not accidentally modified.

------------------

If you'd like more specific instructions to implement this, let us know (including if this is Next-Gen or Classic) :)

Ste 

[David Moore]

Thanks @Ste Wright , yeah I thought this would be the case...

Things are usually pretty logical in JQL, so if you can't figure it out (or find anything on the internet) then you're looking at a work around like you suggested...

I was thinking roughly the same, but we are ScriptRunner customer already so will likely do something very similar but using their workflow extensions and a custom field...

Also, the automation limit of 500 free executions would definitely cap out pretty quick with the "Create Issue" trigger, even with the Sub-Task condition in our instance...

But thanks for the prompt response, I appreciate it...

[Ste Wright]

Hi @David Moore 

Yes, a workflow extension approach is similar to the Automation method, great idea!

For Automation it is 500 executions per product, per month if it is a global rule - but you get virtually unlimited executions if it's project-level. So it would depend what level you apply it to :)

Ste