Cascading select field: dashboard statistic


I just created a custom field cascading type. It works well for our purpose, only the dashboard gadget does not work the way I need. I want to show the issue statisic (or for example a pie chart) listing only the parent values. In the dashboard however, this is not possible, but the whole cascading value is shown.

Eg: Europe - Germany, Europe - France, Africa - Southafrica etc. I would need the piechart showing Europe, Asia, Africa, America, -> so only the first values.

Ist this somehow possible?

Are you planning to change that?




2 answers

I am in desperate need of this function as well.  We use it to show relationships between business segments and their related departments Ex: Parent: IT  Child: Communications, Network, Development, Support...etc But I need to show a pie chart on the dashboard for the "Parent of IT" so we can see as a whole how busy IT is and a separate one for the child so we can see what area of IT is being hit the hardest. I have about 5 other use cases where this functionality is needed. 

0 votes

The point of a cascading select is the second selection, not the first.  The first one is there to group up the options for the second, so that's why the pie chart uses the second one.

I don't believe Atlassian are going to change that, as most of us would want to report on the second field, although it would be nice to have the option.

I've only been asked about this once before, years ago, and I usd the Script Runner to write a listener that picked up issue changes and copied the first half of the field into another (not user editable) select list.

Another use case is, you might have duplicate value for child option for different parent options. For e.g., In a Country/City mapping, Melbourne is in Australia as well as USA. So, you cannot just rely on child option. But sticking to the question, parent value becomes necessary to group the tickets between teams/category or when count of child option is too high/non-unique.

Um, it does.  The problem in the question is that the poster is trying to break it - they've asked to ignore one half of the data pair, which, as you say, means you can't tell Melbourne from Melbourne.

Not exactly trying to break/ignore one half. I can relate to the poster here. I have to group all the issues based on different parent options, as in my case they denote different agile teams. So, I want to understand how many open issues are there in each team and prioritise accordingly. In total, there are more than 50 child options across team and some are duplicate, so grouping based on child is not meaningful here. Now, I understand that first question would be that categorisation of teams based on this custom field is not a good idea at the first place, but I have to do it due to some other challenges. Nonetheless, need of grouping still persists for these field types as dashboard becomes too cluttered otherwise.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Oct 09, 2018 in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

392 views 6 0
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you