Our goal is to calculate the distribution of work type of each project.
To do this, we’d like to be able to count issues sorting them according to a custom field that is set only on the parent issue type. As example, we have Initiatives with a custom field with value “Strategic” and we’d like to display the number of stories descendant of such initiatives.
In your experience, what’s the best way to achieve this?
The best way to achieve your requirement is to implement a new custom dimension using the advanced settings and Javascript code. The idea is that you can tell with the advanced settings to inherit down the value of the custom field from the higher level of the Portfolio hierarchy to the children issues.
You can add to the advanced settings the lines like this:
[jira.customfield_my_cf_inherited]
name = "My custom field inherited from Initiative"
data_type="string"
dimension=true
javascript_code='''
if (issue.fields.customfield_NNNNN) {
issue.fields.customfield_my_cf_inherited=issue.fields.customfield_NNNNN.value;
}
'''
update_from_issue_key="jpoh_parent_5"
Once you save those settings you should see a new custom field available for selection in data import options. After you import this field as a dimension, it will show all the children issues under the parent’s value of custom field.
Note the following about the settings:
-) NNNNN is the ID of the custom field you wish to inherit down.
-) The exact Javascript code might depend on the data type of the custom field. My example is created for the Single select custom field.
-) The setting update_frome_issue_key refers to the 5th level of the hierarchy, which in your case is the top level “Inititative”. The numbering of levels starts from zero which is for the subtasks.
-) There is a simpler solution if you wish to inherit down the standard fields. Please, check the documentation here: https://docs.eazybi.com/eazybijira/data-import/advanced-data-import-options/issue-link-field-dimensions
Hi @janis.plume,
I confirm that the solution suggested by you works like a charm.
I only had to adapt it because my custom filed is a multi-selection one.
During these tests, I’ve found something weird about the import. Every time I updated the custom dimension into the advanced settings window, to force a full reimport I also had to add a random custom field into the Jira import options. Otherwise, I noticed that the import procedure was faster (1min vs 6min) but the updates of the javascript code weren’t taken into account.
Is it a known behavior?
You are right; the changes in advanced settings are not detected automatically for all the impacts. Once you change them, you need to trigger the full re-import for the changes to take effect. The selection of new custom field for import triggers the full re-import. Otherwise you can use either Empty cube option and run import after cube is empty:
or select the full re-import from the data source:
I have another question related to this thread. I’m trying to create a new custom dimension for a JIRA dropdown menu with multiple selections.
I tried this code:
var cfList = [];
if (issue.fields.customfield_12914) {
for (var i=0; i < issue.fields.customfield_12914.length; i++) {
var cfVal= issue.fields.customfield_12914[i].value;
cfList.push(cfVal);
}
}
that is working fine in cases with a single selection.
With multiple selections, this code aggregates the (multiple) values in a single column. e.g. “AAA,BBB” instead of AAA and BBB
Dop you have any suggestions or best practices for this case?
Hi @janis.plume,
I think I need your help with an issue related to this thread.
I’m using the code we already talked about:
[jira.customfield_my_cf_inherited_sp]
name = "Inherited SP"
data_type="string"
dimension=true
multiple_values=true
split_by=","
javascript_code='''
var cfList = [];
if (issue.fields.customfield_12711) {
for (var i=0; i < issue.fields.customfield_12711.length; i++) {
var cfVal= issue.fields.customfield_12711[i].value;
cfList.push(cfVal);
}
}
issue.fields.customfield_my_cf_inherited_sp = cfList.join(",");
'''
update_from_issue_key="jpoh_parent_5"
We are adapting this code on 2 different multivalue Jira fields:
a Select List (multiple choices) available only at the highest level of the hierarchy (Initiative)
a checkbox available at the highest level (Initiative) but for some projects also at lowers levels (usually Epic or Story).
At first, it seemed to work properly. After a deep dive into our data, we found that this code was able to correctly detect value at the level where it was valued, but it wasn’t able to spread this value to the lower levels.
To give you an idea, this is was I see for the field valued only at the highest level (Initiative):
My last suggestion was not in the context of the previous thread. Unfortunately, the multiple value fields cannot be inherited down by the setting “update_from_issue_key”.
There might be two ways to follow for the further implementation of this use-case:
Implement a new scripted field in Jira, which would hold the inherited value of the multiple value custom field in all the lower levels of hierarchy.
A custom measure can be built in eazyBI with a specific formula for this case. This solution depends on the exact outlook of your report and might have performance problems, which is why we do not recommend it often.
