nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

David Geissler_ok7uic

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

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Nic Brough -Adaptavist-

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.

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.

LeKisha Boswell_cb3mkn

Great question and feedback!

James Bullock

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

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.

Thorsten Letschert _Decadis AG_

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

developer