Each issue should have a place in the hierarchy, even those not Tasks or Bugs. Those issues would remain at the Parent level, where no issue types are specified, and I would advise leaving it so.
You might want to make a few changes to your hierarchy to make it work.
Add a definition for the Project level so eazyBI can check on the project of the Task issue and pass the value down for creating a hierarchy
Validate the link name and direction for the “TASK” definition. Please validate the link name and direction for the Bug issues.
Note that the link name and direction should match as you see it from the Bug perspective (see the 1. troubleshooting step Additional Issue hierarchies - Troubleshooting).
Remove the definition for the “BUG” as it is covered by the default Sub-task hierarchy already. It is similar to the first example described in the documentation (Additional Issue hierarchies).
The updated advanced settings might look like this:
((project in (T02_PERS) AND issuetype in (Change)) OR (issueFunction in linkedIssuesOf("project in (T02_PERS) AND issuetype in (Change)", contains) AND issuetype = Epic))
I’ve used this hierarchy an JQL to get such a report " all Epics contained in issues of issuetype ‘Change’ from project T02_PERS "
And mostly it works:
But what about this issues separated by comma?
Projects PERSPRG , T10_CLTCOM are not included in JQL but listed in report…
I’ve found that such cases happen then Epic “contained in” another Change
How can we use in report just Changes from project T02_PERS?
Issue keys separated by comma shows that issue links have multiple to multiple relations between Change and Epic. And that kind of relationship is not supported for building a hierarchy. The new issues hierarchy could be built when an issue has only one parent; in your case, Epic should be linked to only one Change (its parent). If one Epic could be part of several Changes, then there is no hierarchy (Additional Issue hierarchies).
In case of multiple to multiple linking, you can import issue links as separate dimensions without building a new hierarchy. I would recommend creating two issue link dimensions so you could use one or another that suits better to the report:
“Linked Change” representing Change issues
and “Linked Epic” representing Epic issues.
In the report, you may use one of the link dimensions and the “Issue” dimension to see the relation. For example, choose the “Issue” dimension to show Change issues and group them by Projects and then select “Linked Epic” to see the list of linked Epic issues.
Here are details on how to import issue links as dimensions: Import issue links.
The advanced settings for linked Epics might look like the one below. Before using, please double-check and update the link direction and name to match your data.
Making a new hierarchy pays off when there is a hierarchical structure. If you would like to group Epics by linked issues, then you might want to choose a simpler and more robust solution and import issue links as a separate dimension (Import issue links).
If you choose to make the hierarchy, remember to list also the lower hierarchy levels according to Sub-taks or Epic hierarchy. Please review the troubleshooting paragraph, point 5: Additional Issue hierarchies.
Let me remind you the report I’m triying to create:
I was able to create a hierarchy completed with customfield as a measure that returns Epics contained in Change. It was created using Scriptrunner, calculated in Jira, called “cfield_contained_epics”
Second field “cfield_count_contained_epics” returns the size of array of contained epics to Change.
Now I wonder - how to get the sum of epics in the bottom of report?