The fields have to be "statable", which is a dodgy word meaning simply "can be counted". Mostly means select list type fields, by which I mean you can look at a list, like the seven colours of a rainbow. Then you can count usage - "we've got 3 blue issues, 2 orange ones and 92 green". You cannot really do that usefully with text or date fields, it's nonsense - it would be vanishingly rare to get more than one.
I have to disagree with this assessment. There are many cases where you would want to have a generic text field, because you cannot predict what the values need to be, but where the actual values that are used will be some small finite list (customer names, for instance). I really with there was some support for this, even if you had to manually mark the field as allowable. The plugin mentioned below works great if you are hosting your own server, but if you use OnDemand, it seems like you're out-of-luck for the time being...
If you've got a small finite list of customer names, then you should put them in a list. Then the gadget will work. Unbounded fields don't make sense. What happens when I've got 10 distinct customers and a lot of bad spellers/readers/typists? I end up with a long list of duplicate entries. It doesn't work, because you're using the wrong field type.
(Oh, and the case with the dodgy typists - I once worked around this "problem" by writing a field that took the non-stattable data and made it stattable - worked brilliantly for a while, then ran into massive performance issues as the data set grew. The chap who worked out what I'd got wrong said a solution like that simply cannot scale without rewriting part of the core of Jira)
@Tim the plugin is ready for JIRA Data Center , it is now up to Atlassian to add it to JIRA OnDemande , i have been ask by several customers for this plugin to be found within JIRA onDemande. @a display name Unbounded fields don't make sense to you. i think we had that discussion before. :)
We have used this strategy of dropdown lists as well, but there are still many cases where this is out of our control. For instance, the Jira Agile plugin uses custom fields for the Version, Sprint and Epic that an issue is associated with. Those fields are open-ended and are therefore not usable in gadgets. I could also see cases where someone would want to group data based on Requested Date, Affected Version, or even something like Labels. It seems like a solvable problem. The plugin below already provides the functionality, and I can also export the data into Excel and have it make those graphs for me. There is always the potential to configure something that returns meaningless data, but the tool itself should not limit that configuration. If there are concerns for performance, those should just be handled as edge cases (maybe showing an error if the number of categories exceeds some limit or if the underlying query would be too taxing).
I have a similar challenge.
I'm trying to use the Pie Chart Gadget available in Confluence.
I want to report on the status of all stories associated with an Epic, but I don't want the direct status, I need to up a level to the Status Category (i.e. New, In Progress, Completed).
We created a new scripted field (using Script runner) called IssueStatusCategory (issue.status.statusCategory.name). This does the trick inside of queries etc. but I'm unable to see / select this field as a 'Statistic Type' within the Macro.
My scripted field "Template" is setup to use the "Text Field (multi-line)" which (I'm guessing) is contributing to the problem but I don't see another suitable 'template' for this data.
Am I off in the weeds? Am I missing something simple to make this work?
Thanks for the help!
You are right, it is the text field as described above - they're not "stattable". You're not doing anything wrong, the function isn't there.
You could switch to a different method. Have a drop-down select list that you populate in listener code instead of a calculated field.
It's not all I care about, but I am 100% with you on that it is a <bad word>ing useful as a reportable value.
And worse because when you've got a well-configured Jira, it's a shed-load more useful for reporting than having convoluted lists of individual status to work with.
"is it to-do, in-progress or I-don't-care-because-it's-done" is so much more useful than the hundred and eleventy-twelve status that might be thought to be in one of those groups.
I have a situation where a script compares the values of two custom fields that are single selects. It then puts TRUE or FALSE (i.e. match or no match) into a script field. This script field doesn't appear in the list of statistics available for the dashboard pie chart.
How do you suggest I get around that?
I have a field that represents queue ownership, there are only 10 possibilities for it.
The queue is used via a post- function that auto populates when a team is selected via transition.
That field shows which team owns ticket.
The search is based on this query - project = NOC AND project = NOC AND QUEUE ~ Fiber
How can I get the pie field options to show the "queue" field, is there an edit that can be done to query that will cause the field to display?
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events