In Jira, bigger tasks can be split into smaller pieces; thus, we can create task groups that are linked together but can be worked on separately. For example, an Issue can be grouped into smaller sub-tasks. Or an Epic can be split into Stories. eazyBI recognizes those structures and creates different standard hierarchies in the Issue dimension:
- the default hierarchy with Project → Issue levels,
- the Sub-task hierarchy with Project → Parent → Sub-task levels,
- if you have imported the standard Epic Link field then also
the Epic hierarchy with Project → Epic → Parent , and Sub-task levels. - if the Advanced Roadmaps is used, and Parent Link and Epic Link fields are imported then the fourth hierarchy is created based on the Advanced Roadmap configuration (on the Cloud you need to enable the integration and add the hierarchy configuration, see here)
Also, in Jira, there is an option to use issue links to create a relationship between issues; some apps use this to allow Jira users to build even more issue hierarchies. Also, eazyBI offers an option to create an additional issue hierarchy in the Issue dimension. Those additional issues hierarchies need to have a strict structure in Jira to be defined in eazyBI:
- Each child issue has only one parent issue
- Each issue type is used only in one issue hierarchy level.
When you start building the additional issue hierarchy based on issue links, a few important things have to be taken into account. Here I will only mention what in the configuration is different from the simple issue link dimension. But if you are not familiar with issue links and how to import them in eazyBI, you can check this article.
- The issue link dimension for any next level should be described from the child’s perspective.
- There is only one parent issue; thus, the multiple_values parameter should never be true.
- You will need the “update_from_issue_key” parameter to pass the value to children’s issues.
Here is an example of a hierarchy from Jira’s perspective:
- Improvement
- → Feature
- → Epic
- → Story/Bugs
- → Sub-tasks
- → Story/Bugs
- → Epic
- → Feature
Here is how it looks in Jira:
And here is how it can be configured in eazyBI advanced settings. The issue “Improvement” hierarchy is built on top of the “Epic” hierarchy by adding two additional levels “Feature” and “Improvement”. Each link should represent the one level above - define “Improvement” from a “Feature” perspective, define “Feature” from “Epic” perspective and pass the value down to children issues with “update_from_issue_key”:
##Issue is child of Improvement
#import reference to Improvement for Feature
[jira.customfield_improvement]
name = "Improvement"
inward_link = "is child of" #link name and direction from Feature perspective
issue_type = "Improvement"
dimension = true
update_from_issue_key = "customfield_feature" # pass down values to children of feature
##Issue is child of Feature
#import reference to Feature for Epic
[jira.customfield_feature]
name = "Feature"
inward_link = "is child of" #link name and direction from Epic perspective
issue_type = "Feature"
dimension = true
update_from_issue_key = "epic_key" # pass down values to children of epic
## Issue hierarchy Improvement
[[jira.issue_hierarchies]]
name = "Improvement"
all_member_name = "All Issues by Improvement"
levels = [
#two custom levels above default epic hierarchy
{name="Improvement",key_column="customfield_improvement",issue_type="Improvement"},
{name="Feature",key_column="customfield_feature",issue_type="Feature"},
#default set of levels for epic hierarchy, do not change it
{name="Epic",key_column="epic_key"},
{name="Parent",key_column="epic_parent_key"},
{name="Sub-task",key_column="subtask_key"}
]
In this use case to create a new issue hierarchy, in the eazyBI data source import options field “Improvement” and “Feature” needs to be selected for importing. After the import, a new issue hierarchy is created.
The report “Issue custom hierarchy improvements” is based on the configuration above:
Remember that you should build an issue hierarchy based on one of the two default hierarchies (Epic hierarchy or Sub-task hierarchy). Parameters update_from_issue_keys and bottom levels of the hierarchy should be of the same default hierarchy and should be used with the default setup. Build any level on top of those bottom levels.
-
Rules for defining update_from_issue_key correctly:
-
when defining any higher-level link custom field, link it to the field storing the issue key of the next lower issue-level
-
if the next lower level is Epics and the hierarchy is defined upon epic hierachy, use
update_from_issue_key = "epic_key" -
if the next lower level is a standard issue level (parent) and the hierarchy is defined upon sub-task hierarchy, set
update_from_issue_key = "parent_issue_key"
-
-
Rules for defining the bottom levels of the hierarchy correctly:
- use those as bottom levels if the hierarchy is defined upon Epic hierarchy
{name="Epic",key_column="epic_key"}, {name="Parent",key_column="epic_parent_key"}, {name="Sub-task",key_column="subtask_key"}- use those as bottom levels if the hierarchy is defined upon Sub-task hierarchy
{name="Parent",key_column="subtask_parent_key"}, {name="Sub-task",key_column="subtask_key"}
See other issue hierarchy examples as well as troubleshooting steps in the documentation: Additional Issue hierarchies
