Configuring Fields and Screens

Overview To help you tailor JIRA to your organisation's needs, JIRA enables you to manipulate the display and behaviour of issue fields ('Summary', 'Description', 'Issue Type', etc). You can: Change a field's description Make a field hidden or visible Make a field required or optional Add your own values for 'Issue Type', 'Priority', 'Resolution' and 'Status' Create new 'custom' fields Enable a rich text renderer for (some) fields Position fields on a screen Choose which screen should be displayed for each issue operation (e.g. 'Create Issue', 'Edit Issue') or workflow transition (e.g. 'Resolve Issue', 'Close Issue') Diagram: How Fields, Screens and Workflow interrelate Gliffy Zoom

On this page: Overview Diagram: How Fields, Screens and Workflow interrelate Concepts In this section: Configuring Built-in Fields Defining 'Issue Type' Field Values Associating Issue Types with Projects Defining 'Priority' Field Values Defining 'Resolution' Field Values Defining 'Status' Field Values Translating Resolutions, Priorities, Statuses and Issue Types Adding a Custom Field Configuring a Custom Field Creating Help for a Custom Field Specifying Field Behaviour Associating Field Behaviour with Issue Types Configuring Renderers Defining a Screen Associating a Screen with an Issue Operation Associating a Screen with an Issue Type

Concepts

Some key JIRA concepts include:

• Field Configuration --- a set of definitions for all fields, comprising: each field's description; whether each field is hidden or visible; whether each field is required or optional; and what type of renderer to use for each text field.
• Screen — defines which fields are present on a screen, and their order. (Note that a hidden field can be present on a screen, but will still be invisible.)
• Screen Scheme — associates different screens with different issue operations (e.g. 'Create Issue', 'Edit Issue', 'View Issue').
• Workflow — defines the steps (i.e. statuses) and transitions to other steps that an issue moves through during its lifecycle. Screens can also be mapped to different transitions of a workflow.
• Field Configuration Scheme — associates Field Configurations with issue types, which in turn is applied to projects. This allows you to specify different behaviours for a field, for each type of issue in a given project.
• Issue Type Screen Scheme — associates Screen Schemes with issue types, which in turn is applied to projects. This allows you to specify different screens for a particular operation (e.g. 'Create Issue'), for each type of issue in a given project. For example, you could use one screen when creating an issue of type 'Bug', and a different screen when creating an issue of type 'Task'.
• Workflow Scheme — associates Workflows with issue types, which in turn is applied to projects. This allows you to specify different workflows for each type of issue in a given project.
• Issue Type Scheme — is applied to projects and defines (or restricts) which issue types are available to those projects.
  If the Field Configuration Scheme, Issue Type Screen Scheme and Workflow Scheme associated with a given project contain associations with other issue types that are not specified in the project's Issue Type Scheme, then those other issue types will be ignored by the project since the project's Issue Type Scheme restricts what issue types the project can use.