Cannot add Custom Field type 'Short Text (plain text only)' to Jira Dashboard Pie Chart

[Michael Green]

Hi,

We have a number of custom fields added to our issues.  They are all type 'Short Text (plain text only)'.

We want to be able to group issues by one of these fields in pie chart e.g. customised field for Team, Department, Organisation etc

However when I add a Pie Chart Gadget to a Dashboard and then select 'Statistic Type' none of these custom fields show.

Why can't Jira group by text fields ?

[Nic Brough -Adaptavist-]

Because text fields do not contain data that can be grouped.  There's no point in grouping by text - the nature of the data is that every entry you have could be (and probably is) different, so if you did it in a pie chart, you'd simply end up with X slices, all containing a single issue.

If you think you should be able to pie-chart an item of data that you have in a plain text field, then you've got a simple problem - you've used the wrong type of field to hold the data.  You should change it to a select list.

[Michael Green]

Actually the point is that the data wouldn't be different - we are using text fields for Team, Department, Organisation..... because Jira FAILS to with its User set up / information i.e. you can't say a User is a specific Team, Group, Organisation or Company.  But I take your point that a pick/select list might work - but that would then require occasional updating.

Is there a list of which custom field types WILL work with Dashboard gadgets e.g. pie charts ?

[Nic Brough -Adaptavist-]

Not quite.  The logic Jira is using here is that a text field could be anything and it is very rare that a team of humans will get text entry identical every time (heck, it's around 90% that three of us will get it wrong iin a surprisingly short time, and guaranteed, and faster, if there's more than three)

So, a text field is the wrong choice when you want to do any form of "counting" type reporting.

The custom fields that you can do "count" reporting on are any field that has a "bounded" list of options instead of free-form data.  "Bounded" is a clumsy term, but I've not found a better one yet.  It means that there is a fixed list of options that could go into the field, rather than an  open one where you could put anything you want in. 

An example of a bounded list might be "visible colours for humans" - most of us would probably put the seven colours of the rainbow in, but then people with a bit more colour design experience might want to add a huge swathe of imaginary colours (pink for example - it's not a frequency of photons, our brains construct it), or real ones that do represent frequencies in between the main seven colours.  Or you went to your DIY store and found a hundred and eleventy twelve variations of "magnolia". 

But however long or short you make the list, it is "bounded" - you can count the number of available options.  With text, you end up with silly numbers - even sticking to the most basic 27 characters (the alphabet plus space) that most English uses, an 80 character summary field has half a googol number of options.  No computer is going to handle that well.

I've spent a lot of time removing non-performant plugins from Jira when they try to make non-bounded fields reportable like this.  It just doesn't work.

I personally think there's an argument for treating dates as bounded, as it's quite rare for people to end up with more than a couple of hundred in any given report, but I can't make any argument for making text fields groupable.

[Michael Green]

Thanks for the detailed explanation @Nic Brough -Adaptavist-   However whilst I understand - it doesn't get me any closer to meeting my requirement which is to group issues by Team, Department, Organisation etc

Why doesn't Jira support Teams or adding additional information to the User object ?

[Nic Brough -Adaptavist-]

Jira goes for the more (scaled) Agile idea that your teams, departments and organisations are not that useful to the basic principle of "we deliver stuff"

Your question 

>Why doesn't Jira support Teams or adding additional information to the User object ?

Really does get to the core of two big things when people start trying to be Agile.  I would like to steal exactly what you have said there as it's a perfect starting point for some discussions, but I can't as it is, because a) it's yours, and b) you've already moved past it.

I'm going with an oversimplification, but in (scaled) Jira systems, board = team.

Your teams should be working off a board that works for them.

[Michael Green]

@Nic Brough -Adaptavist- Your reply makes zero sense to me.  The agile issue is irrelevant to the requirement / discussion here as the issue relates to contractual and inter-organisation responsibilties.  Its not an agile question and nothing to do with boards either.

it doesn't get me any closer to meeting my requirement which is to group issues by Team, Department, Organisation etc

[Brian Northgrave]

I have exactly the same issue as Michael, so was also just as confused by your reply. @Nic Brough -Adaptavist- really you explain how you see it being used as opposed to how we (customers) ARE using it ;-) Classical problem in software engineering. Going back and changing 1000s of jira items to match how you think it should be used is not appealing (sigh). Unless I can change the type wholesale without having to re-enter the custom field

[Nic Brough -Adaptavist-]

I'm afraid I can't really explain it differently again.

It's just simply that a text field is not the right one to use when you want to be able to count the different options in it.

It's not about software engineering, unless you think the engineers should be implementing functions that are utterly useless just because someone does not understand their data.

A pie chart based on a text field would be useless.  It would show one "slice" per issue, whatever the text content, because text fields are logically all different.