1. How do I get a list of all the fields in JIRA? 2. How to I find usage for each field?

David Geissler
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
November 15, 2017

I am looking to clean up JIRA and create a baseline to onboard new projects with all the extra distractions of unused fields.

 

1. How can I get a list of all the fields in JIRA?

 - per issuetype

2. How do I get the usage report for each field? 

3. Are there any adverse affects to hiding unused fields?

 

Thanks -d

2 answers

1 accepted

10 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 15, 2017

Good plan.  But I'm afraid it's not as easy as it should be.

There are loads of types of field in Jira as far as we humans are concerned:

  • System fields that Jira always has on issues.  There are four broad groups of these
    • Structural ones that are not really fields - Project, issue type and status.
    • Non editable fields - created, updated
    • Mandatory system field - summary, resolution (ok, resolution is not mandatory, but you should treat it as a field you always have to think about, whatever your users say about how much they don't want to use it)
    • Optional system fields - assignee, reporter, environment, due date, comments
    • Note that applications and add-ons can add to those - Service Desk, Software and Portfolio will add things like Epic Link, initiative, request, yadayadayada
  • Custom fields

However, the only system field I would bother analysing is "environment".  The others are either too useful to get rid of, or you can't.

So, to answer question 1:  Go to Admin -> Issues -> Custom fields.  That's the list of fields you want to look at (and tack "environment" on to the list)

Question 2

For each field, run the JQL  "<field> is not empty".  This will return a list of all the issues with content for that field.

This does not tell you a massive amount though.  I find it far more useful to save each one as a filter, then go to a new dashboard and add a "filter statistics" gadget, using "project" as the statistic.  This way, it tells you the number of issues using the field by project.  Far easier to read, and can lead you to "hey, you guys are the only people using this field, how about we rationalise it" conversations.

Question 3:

Not hugely, but it can make searches a bit more frustrating for a user, if they assume that a field they see in their project exists in someone else's project. 

You won't get any technical gain from hiding fields, it just simplifies some of the views for users.  If you want to make things a bit faster, change the field contexts, so they only belong to a sub-set of projects and/or issue types.

James Bullock October 24, 2019

Tardy reply ... followed some breadcrumbs...

Realizing there are different kinds of thing that look "the same" is an immensely useful thinking hack.

Your field types reflect the class / object categoryies put forward in what's colloquially known as "The Color Book."(*) Net, there are several kinds of things in your system: domain objects, workflow, infrastructure, and internal "helpers." This take suggests encoding these categories with colors.

(*) Java Modeling in Color with UML (Coad, de Luca and Lefebvre), really not important for it's Java-ness, or UML-ness. Important for the categories / colors modeling schema, and for the brief work-wrangling chapter that by popular demand developed into a stand-alone book on "FDD: Feature-Driven Development."

Carol Szabo October 5, 2020

Great answer, but to me it still does not answer question 1:
How can I get a list of all the fields in JIRA? Preferably with a description next to them.

My problem is simple: I would like to sort the issues in descending order of that field that identifies the issue. (not the id which is random, but that string that starts with the project moniker and followed by a number). I never have to enter that field so its name is rarely (if ever displayed). When I write a filter, a drop down shows up which shows maybe 20 fields but it informs me that there are 944 fields available. I tried to guess the field name but it did not work. It does not start with Issue, it is not id, not name, I started trying the letters of the alphabet at random. Unfortunately for some of them more fields exist than fit the dropdown, so I have to go to 2 letter combinations.

There must be a better way.

So far I found out that the name of the field is "Key", by exporting a query to CSV and requesting that all fields are included and looking at the generated file.

No. "Key" was not one of the fields listed in the file, but "Issue Key", which is not one of the valid field names was, so I thought, I'd try Key, dropping "Issue ".

BTW: There are valid field names such as "Issue Type", "Issue Category", etc. that start with "Issue", more than fit a drop box, but "Issue Key" is not one of them despite the column heading in the generated csv.

The above story is for illustration purposes only. I come back to the question:

When writing a JQL one needs to know the names of the fields. How does one find out what they are (especially if one is not a Jira Administrator or a Project owner or some person with high privilege in Jira)? Non-scrollable dropdown boxes aren't helpful.

Like Michael Farhat likes this
Thorsten Letschert _Decadis AG_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
October 6, 2020

Hi @Carol Szabo ,

regarding the system fields, the official documentation might help, e.g. https://confluence.atlassian.com/jirasoftwareserver/advanced-searching-fields-reference-939938743.html for Jira Software.

All the remaining fields present on your instance have been added manually (by your administrators), therefore the responsibility for a proper naming convention lies with them. If this is lacking right now, it might be the best idea to reach out to them.

Cheers
Thorsten

Like # people like this
K_ Yamamoto
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 25, 2022

FYI - you might find it helpful to query system fields via REST API like as below:

  • https://EXAMPLE.atlassian.net/rest/api/3/field/search?type=system&expand=key,isLocked,searcherKey

Reference: developer.atlassian.com

Like Tatsuya Uekusa likes this
Carol Szabo April 26, 2022

@K_ Yamamoto Interesting but it is not enough.
1. It only lists the system fields.

2. It requires admin privileges to run. How is a mere user of Jira able to find the names of the fields so he can run a query? Are only admins supposed to write queries?

3. The feature is experimental. It does not seem to work in my Jira installation.

GET /rest/api/3/field (deprecated) seems much more useful, but it is still too complicated to use. Having a button on the query builder page or some other user interface to pick a field name seems to me a sorely missing feature.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 26, 2022

Eh? "How is a mere user of Jira able to find the names of the fields so he can run a query?" - why would they be looking at a list of fields to find out what they want to query?

K_ Yamamoto
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 26, 2022

@Carol Szabo Sorry for posting an irrelevant comment out of no context. I should've posted it as a new thread as I just wanted to let the community people know there's a related REST endpoint. One thing to add, you can query custom fields with it:

^ be aware this endpoint is available for the Cloud platform.

Carol Szabo April 26, 2022

@Nic Brough -Adaptavist-  See my comment from October 5, 2020 for a practical example. The example is about a required standard field, but depending on how various forms are designed the name of any field may be missing from all forms, being replaced by some description of its meaning. As a result the only way to figure out what the actual name of the field is is to read the description of all the fields in the field list and pick the one whose description looks like it's matching the desired meaning of the field.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 27, 2022

But how does a list of field names help them? 

If someone is searching your Jira for something, they're going to come from one of two places - someone has asked them to look in Jira and will almost certainly have told them what to look for, or they are an existing user, working in a project and they'll be identifying which field they need to search in there by looking at the actual data.

Carol Szabo April 27, 2022

@Nic Brough -Adaptavist- Can you explain to me what data can you look at to find out that the name of the "Issue Key" field is "Issue Key" or "Key"? This fieldname does not appear anywhere in the project despite being a required field in all issues. It took me a few hours to write a query that sorted the issues by issue key.

As I explained above, when I look at an issue I see "Root Cause Link: ABC-123", How does this help me find all issues that do not have an assigned root cause? The name of the field may be RootCauseLink, but usually it is not. It can be RootIssue, or RootCause, or LinkToRoot, or Custom112345.

A list pairing the actual name with a description of the field would be very useful to solve this problem.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 28, 2022

>Can you explain to me what data can you look at to find out that the name of the "Issue Key" field is "Issue Key" or "Key"?

By actually looking at your system.  For example, any search will give you headers:

Screenshot 2022-04-28 at 10.39.07.png

> "Root Cause Link: ABC-123", How does this help me find all issues that do not have an assigned root cause?

It depends on what that data is from.  There are three things that spring to mind:

  • If you are quoting a block of text in an issue, then yes, you have a problem, your people are putting the link into the wrong place.
  • If it is a proper field with a value of ABC-123, then the JQL  ' "Root Cause Link" is empty ' will get you all issues with the field being empty
  • If it is referring to an issue link, then you'll need to be looking at the functions that look at issue links.

This sort of takes me back to the underlying questions I'd like to ask, the ones that look at why you think you want this list.  It sounds like you are trying to write JQL without actually looking at your data or setup.  Extracting a list of fields might help you a bit if you're going to do that, but you'll find it far easier to write JQL in the advanced search bar, and maybe a second window where you're looking at the data you want to be searching for in your issues.  I think I'm asking what you are trying to achieve, not about how you're getting there though.

Carol Szabo April 29, 2022

Maybe the issue has been fixed. When I started this discussion the displayed name of the field wasn't usable in JQL. Instead of "Key" the header displayed "Issue Key" which did not work in JQL and some other fields that I was interested in had totally different display string from the field name. This is what I am talking about in the comments.

0 votes
LeKisha Boswell March 8, 2018

Great question and feedback!

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events