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; } } }

Question about Fields...

NickW

Hi All

I am sure there must be an answer to this somewhere but I just cant find it so I will appologise up front if this is stupid.

I have installed JIRA and am now working on creating the workflow etc.

I have added in various custom fields. But there are a number of what I guess are system fields such as Affects Version, Assignee, fix version/s etc.

Is there a list of these anywhere and how they behave? Can I delete them?

Thanks in advance

Nick

Accepted answers

Penny Wyatt (On Leave to July 2021)

Hi Nick,

It's not possible to delete the System fields, because many of them are associated with special behaviour in JIRA. However, if you don't need them you can hide them, which achieves the same purpose. The docs for this are here:

https://confluence.atlassian.com/display/JIRA050/Specifying+Field+Behaviour#SpecifyingFieldBehaviour-Hidingorshowingafield

I haven't found a proper list of the system fields in a quick search of the docs, so here's a quick brain-dump:

Affects Version/s - a version picker, which references Project Versions that you can create on the project admin screen. (e.g. 5.0, 3.1). Affects Version is intended to contain the version of the product where the issue was found.
Assignee - a user picker that contains the user that's meant to be working on the issue right now.
Attachment - files uploaded to an issue
Comment - a text field for commenting on an issue
Component/s - a component picker, which references Project Components that you create on the project admin screen. (e.g. UI, Database). Components can have a person who is the Component Lead, who gets auto-assigned any issues with that component set.
Description - the main text field for describing the issue
Due Date - a date picker for when the issue should be fixed by
Environment - a text field for describing the environment in which the issue occurred (e.g. "IE9 on Windows 7")
Fix Version/s - a version picker, this is intended to contain the version of the product where you fixed the issue.
Issue Type - whether the issue is a bug, story, improvement, etc. You can add more issue types from the Issue Types admin screen.
Labels - labels are short text strings for grouping issues into categories. Similar to Components except that users can put any arbitrary value in there.
Linked Issues - an issue picker field, for joining related issues together
Log Work/Time Tracking - allows a user to specify how much time they have spent on an issue, and plan how long an issue will take. This shows up in nice bar charts on the view issue page.
Priority - how important an issue is (blocker, critical, major, etc). You can configure these from the Priorities admin screen.
Reporter - a user picker that contains the user that created the issue.
Resolution - how the issue was resolved (fixed, duplicate, Won't Fix, etc). You can configure these from the Resolutions admin screen.
Security Level - who can see the issue. By default everyone with browse access to the project can see all issues in it, but you can set it up so that some issues are limited to particular users.
Summary - a single-line text field that should contain a short summary of the issue

To pick an issue at random from our public instance, https://jira.atlassian.com/browse/JRA-9 shows many of these system fields in action.

Hope this helps!

All comments

Penny Wyatt (On Leave to July 2021)

Hi Nick,

https://confluence.atlassian.com/display/JIRA050/Specifying+Field+Behaviour#SpecifyingFieldBehaviour-Hidingorshowingafield

I haven't found a proper list of the system fields in a quick search of the docs, so here's a quick brain-dump:

To pick an issue at random from our public instance, https://jira.atlassian.com/browse/JRA-9 shows many of these system fields in action.

Hope this helps!

Nic Brough -Adaptavist-

You can't delete system fields, but you can "hide" them on a project by project (or global) level. The only one you cannot "hide" is the Summary - it's mandatory on all issues. There's no harm in losing any of the fields.

I'd suggest most of them are pretty useful in most cases (reporter, assignee, description), but the ones I'd think about "dropping" for some projects are:

Components - in really simple projects which aren't much more than to-do lists

Versions - if you're not tracking versions, sprints or releases in a project

Timetracking / worklog - if you're not doing time tracking

Have a look at https://confluence.atlassian.com/display/JIRA/Specifying+Field+Behaviour - there's a really handy box in the middle which (accidentally) lists all the "system" fields, under the heading of

Modifying field behaviour"

M. P.

And does anybody know how to hide this system field in a "beautiful way". We have some simple issue types that doesn't need all this Priority, Affected Version, Components.

Unfortunately when we hide them on Issue type Level you can see Issue Type Field and after bigggg space and than Label Field.

Probably this system fields have predefined places, so if we hide them, this place is just empty, but another field doesn't slips up. Is there any possibility to configure it ?

Thanks in advance!

Penny Wyatt (On Leave to July 2021)

Hi M.P.,

That's odd, I've never seen that behaviour. There's no "predefined places" for fields - just predefined blocks of fields (dates and people on the right; summary, details, description and activity on the left). On my own personal JIRA instance I've hidden most of the system fields and the leftover ones squash up nicely.

Do you perhaps have a third-party addon installed that might be causing this? You can test this by going to the Manage Add-ons page in administration and clicking "Enter safe mode" in the footer.

Cheers,

Penny

M. P.

Hi Penny,

I've tried your proposal and disabled plugins by "Entering safe mode", unfortunately it doesn't changed. Space between Issue Type field and Label fields is still there, like two field were missing, in this case Priority and Affected Version.

JIRA Version 6.2.7

Delfino Rosales

Issue fields

By default, Jira provides a few fields for your issue types that we think help provide context to your project's work:

Project

The parent project to which the issue belongs. Every issue must belong to a project.

Key

A unique identifier for this issue. For example, ANGRY-304 (The characters to the left of the hyphen represent the project the this issue belongs to). This field is auto-populated by Jira.

Summary

A brief, one-line summary of the issue. For example, "Red Angry Nerd is scary." This is a required field.

Type

A category for the issue, like "Task", "Epic", or "Bug".

Status

The stage the issue is currently at in its lifecycle

Priority

The importance of the issue in relation to other issues. (See below for a list of priorities).

Resolution

A record of the issue's resolution, if the issue has been resolved or closed.

Affects Version(s)

Project version(s) for which the issue is (or was) manifesting.

Fix Version(s)

Project version(s) in which the issue was (or will be) fixed.

Component(s)

Project component(s) to which this issue relates.

Labels

Labels categorize and can group related issues.

Environment

The hardware or software environment to which the issue relates.

Description

A detailed description of the issue.

Links

A list of links to related issues. (Strikethrough text, like this, indicates that an issue has been resolved

Assignee

The person to whom the issue is currently assigned. Note that you cannot assign issues to a user group.

Reporter

The person who entered the issue into the system.

Votes

The number shown indicates how many votes this issue has.

Watchers

Number shown indicates how many people are watching this issue.

Due date

The date by which this issue is scheduled to be completed.

Created

The time and date on which this issue was entered into Jira.

Updated

The time and date on which this issue was last edited.

Resolved

The time and date on which this issue was resolved.

Estimate

The Original Estimate of the total amount of time required to resolve the issue, as estimated when the issue was created.

Remaining

The current estimate of the remaining amount of time needed to resolve the issue.

Logged

The sum of the Time Spent from each of the individual work logs for this issue.

Development

If you use Bitbucket to manage your code repositories, you can create code branches in your code development tools directly from Jira issues. Only available in Jira Software projects, and only available to Jira Software users.

Agile

Lets you view your issue on your Scrum or Kanban board. Only available in Jira Software projects, and only available to Jira Software users.

Service project

Lets you view request participants and view the equivalent request in the customer portal. Only available in Jira Service Management projects, and only available to Jira Service Management users.

Jason Armistead

This information does not align with what I am seeing in my company's Jira Cloud instance.

There is a "Due Date" field, that appears to be a Custom Field

BUT there is also a "Due date" field (notice that "date" does not have a capital "D")

This seems to suggest that "Due date" is the correct pre-defined field name, and not "Due" as written by Atlassian Team member Delfino Rosales (above)

If this is correct, please update the comment (or at least put another comment confirming I am correct)

Thanks!

Delfino Rosales

You're right, I missed the word "date" but it is fixed now, thanks for that!

Jason Armistead

Can this information please be added to the Jira Cloud documentation? It is important for project Admins to understand what fields are there "out of the box" (which I consider "System" fields), but when I searched for an answer online in the documentation, there wasn't one. The only place I found it was here in the Community forums., which is really not how documentation should be. Prior to this It's only by looking at all the fields, and then eliminating the Custom fields, that I could figure out the "System" ones.

On my Jira Cloud instance, some previous Admin had created their own custom "Due Date" field because they apparently didn't know there was already an existing "Due date" field they could use. Thankfully their custom field wasn't being used anywhere, otherwise trying to untangle this mess would have been much more complex!

Maybe when showing fields Jira could indicate the "System" fields with some sort of icon, so that it is 100% clear that they are not custom, and will always be there and (hopefully) can't be deleted.

Welcome!

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

Quick Links

Find more posts tagged with

jira

field

administration