Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,301,315
Community Members
 
Community Events
165
Community Groups

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

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

7 votes
Answer accepted

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.

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."

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.

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 bongartz likes this
K_ Yamamoto Atlassian Team Apr 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

@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.

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 Apr 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.

@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.

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.

@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.

>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.

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.

Great question and feedback!

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Events near you