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...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Tim, I have been contacted recently for having this issue sorted out for a customer willing to switch to Jira On Demand. Let it be clear that your are not alone, feel free to contact me.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@marc trey I was a bit puzzled by your response, Marc - Are you saying that you have found a solution for this issue that will work for OnDemand customers?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
(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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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. :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Michele,
You can have a look a this plugin , it add statistic for those custom fields:
Best regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I also need the "Team" field to be in the options.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To add an observation to this sub-discussion - Jira dashboard Pie Chart gadget does not support StatusCategory as a Statistics Type. Bummer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
+1 that lack of StatusCategory is a bummer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
StatusCategory is all I care about. I've over a few hundred servers to migrate, and I just want to know % Done, but doesn't happen with Status as Closed (meaning not migrating). Huge Bummer!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I ended up in this community because I was looking for a way to add StatusCategory as a Statistic Type but it seems there is no way out from the thread of the conversation.
@atlassian are you doing anything about this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
G>
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must assigne a statable search template that match the return type of your custom scripted field.
Here is a full example with a numeric value jira-stattable-searchers not working with scriptrunner
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
you need to change the searcher for your "queue" custom field , see configuring a custom field :
ex :
2356662647.png
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.