Configuring Fields and Screens

Overview

To help you tailor JIRA to your organization's needs, JIRA enables you to manipulate the display and behavior of issue fields ('Summary', 'Description', 'Issue Type', etc). You can:

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 behaviors 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.
    (info) 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.

Related topics

Was this helpful?

Thanks for your feedback!

26 Archived comments

  1. User avatar

    Janet Albion [Atlassian]

    Hi,

    I  personally think this diagram make my it easier to understand JIRA. It just make JIRA concept easy to digest for beginner.

    25 Nov 2009
    1. User avatar

      Hui Zhou

      With the diagram, It is very clear for me to understand these concepts.

      11 Jun 2010
  2. User avatar

    Anonymous

    Hi

    when i defined different screens for project conf (issue type screen scheme) and project's workflow transition; which one has priority; Is it possible to define a screen just for a transition other than project's issue type screen scheme. When i tried eg. when i create an issue, actual screen seems as issue type screen scheme not as transition screen

    12 Oct 2011
    1. User avatar

      Giles Gaskell

      Hi there,

      'Screens' associated with 'screen schemes' (which in turn are associated with 'issue type screen schemes') determine the fields seen whenever you perform an 'issue operation', which includes 'creating', 'editing' or 'viewing' an issue.

      On the other hand, 'screens' associated with 'workflows' (which in turn are associated with 'workflow schemes') determine the fields seen (in a dialog box) whenever you 'transition' an issue to a new status in the issue's workflow.

      Hence, neither of these different 'screen' associations take priority because they appear under different circumstances - one when you create/edit/view an issue and the other when you 'transition' an issue through its workflow.

      To define a screen for just a transition, first define a screen and apply it to the relevant transition. See the Working with Transitions section of the Configuring Workflow page for details on applying predefined screens to transitions.

      Hope this helps!

      Cheers,

      Giles.

      12 Oct 2011
      1. User avatar

        Joe Rohan

        This is the best thing I've ever read! Thank you!

        28 Mar 2013
  3. User avatar

    Anonymous

    Hi,

    I am interested in finding out if fields can be hidden or displayed based on logic.

    For example, when i move a logged issue to "Resolved" status, if i indicate that it was resolved with code change, then the fields like "Check in Label", "Release ID", "component",  etc should be mandatory fields to fill out

    If i indicate it was resolved with a document change, then only "Name of updated document" field should be mandated and other fields should not appear at all.

     

    Rashmi

     

    10 Nov 2011
  4. User avatar

    Anonymous

    Hi

     

    I created a project that had 2 custom fields and description.  When i ordered the screen it leaves the description at the bottom.  However the order is meant to be

     

    Description

    Custom 1

    Custom 2

    24 Nov 2011
  5. User avatar

    Anonymous

    I did quite a search and cannot find the solution for configuring the same field on different screen as mandatory or not. For example, I have a field "Fixed Version", when I log an issue, I do not need this field as mandatory field, but when I resolve this issue, I need it to be mandatory. How can I achieve this? I use different screens for creating issue and resolve issue.

    Any help is appreciated!

    25 Jun 2012
    1. User avatar

      Giles Gaskell

      Hi there,

      There are two ways in which you could achieve this:

      1. Using the JIRA Suite Utilities plugin:
        1. Install the JIRA Suite Utilities plugin in your JIRA installation.
        2. Make the 'Fix Version' field optional in your project's field configuration(s).
        3. In your project's workflow(s), apply a 'Fields Required Validator' to your resolve transition.
          (info) See JIRA Suite Utilities Workflow Validators for details.
      2. Making the 'Fix Version' field mandatory in your project's field configuration(s).
        • Omit the 'Fix Version' field from your project's create issue screen(s).

      The first approach provides greater flexibility.

      The second approach doesn't require the JIRA Suite Utilities plugin to be installed. However, you aren't provided with an option to specify a fix version when an issue is created.

      Hope this information helps.

      Cheers,

      Giles.

      25 Jun 2012
      1. User avatar

        Anonymous

        That's so helpful. Thank you so much for your quick response, Giles.

        25 Jun 2012
  6. User avatar

    Anonymous

    Hi,

    I'm looking for a way to have people working on my projects (each representing various teams: TW, WD, ID, AE, AP, etc.) be seen on each issue screen for the project. Now it appears that I can define the "people" at the project level, but then this info is not displayed automatically anywhere else. Is there a way to have those fields populate onto the issue pages for a project?

    Otherwise, I've seemingly accomplished this via custom fields on the issue screens - where I enter the team members. But could these custom fields inherit, populate, and/or sync to the project defined roles? OR to those fileds on other issue screens within a project? So for example, Project X has 2 issue types:

    On issue type 1 screen, I would enter fields for various people/groups/roles on the project.

    On the issue 2 screen,  I want those people/roles to be seen, but rather than enter each of them again, the fields would be inherited/populated and sync'ed to issue 1?

    Is this possible?

     

     

     

    01 Aug 2012
  7. User avatar

    Juan Felipe Cardona

    Hello

    It seems that the link for 'custom' fields in the Overview section is pointing to the wrong place.

    12 Oct 2012
  8. User avatar

    Anonymous

    Hi,

    I'm a little confused re context and screens... what's the easiest way to accomplish this:

    -Add a new text field called RID to only one project (key PRJ) and have it appear on the issue create and edit screens for that project just below the issue summary.

    This should not affect any other project.

    Thanks!

    26 Oct 2012
    1. User avatar

      Juan Felipe Cardona

      During the creation of the custom field you can restrict its usage both to an issue type and a specific project; with that you are at least ensuring that the field won't appear in other projects.

      Now you will want to make sure that it appears in the correct screens and order in your project. For this you'll have to make sure about two things:

      1. That the field is "shown" in your field configuration (a project has only one Field Configuration Scheme, and a Field Configuration Scheme has at least one Field Configuration).
      2. That the field is visible in the screens where you want it to be (a project has only one Issue Type Screen Scheme, and an Issue Type Screen Scheme has at least one Screen Scheme, and a Screen Scheme relates a screen with one of this actions: create issue, edit issue or view issue).

      After checking that you can go to your screen and just change the position of the field.

      I hope that helps you.

      26 Oct 2012
  9. User avatar

    Anonymous

    Hi

    Help me to add a new field which show a message above when an issue created.

    When i create an issue it show more fields required. When above all show this like"This for wiki project". How can do that??

    Regards

    Raj

    21 May 2013
    1. User avatar

      Juan Felipe Cardona

      Hello Raj

      I don't think I'm getting your idea... but let me try to explain a little about the required fields.

      You have two options make a field as required:

      1. In your Field Configuration just mark it as Required. This will ensure that your field is always required in any screen, even from the creation. This way you cannot define the message; JIRA predefined message will appear.
      2. Make the field as optional in the Field Configuration but handle it with a workflow condition so that only in certain transition it is required. This way you can define the message to show when the user doesn't fill the field.

      I hope this helps.

      21 May 2013
  10. User avatar

    Edgar Maistry

    Hi, I'd like to configure the Build&Release screen so that I can choose parameters passed to BAmboo from a drop down list. Is that possible?

    16 Jan 2014
  11. User avatar

    Accounts Accounts

    Hi There, 

    I've got a problem as I've lost my "Fix Version/s" field option in my projects.

    It's in the system configuration and should be showing on all screens but it is missing when I actually try and get it on the project.  

    It's a build in field but I used the "Advanced" section of the Fields Config (in Custom Fields) to make another field that carried out the same function (Version Picker (multiple versions)).

     

    Can you help?!  I would just stick with this custom value but JIRA Agile puts "Fix Version/s" as default on the Agile config & I don't want to have to change for all projects.

     

    Thanks!

    13 Nov 2014
    1. User avatar

      Warren Thompson

      Hi Accounts Accounts,

      I'm not sure what could be causing the field to not show. There's a few things you could check, as an Admin you should be able to see an Admin button when you're viewing an issue. Clicking that will give you options to add the field, or see if it's available. If that still doesn't work for you, I'd suggest contacting our Support team and they can assist you further.

      Thanks,

      Warren

      16 Nov 2014
  12. User avatar

    alexandru pau

    Hi guys 

    Is there a way I can use in the same project different field configurations ?

    I have a field which is optional in default field configuration. However in the workflow, for the transition from "open" to "in progress" i need to use a customized field configuration where I set that field to required. 

    Thanks

    Alex

    05 Dec 2014
  13. User avatar

    Antigone K

    This whole scheme thing seems prohibitively complex, especially since there's no documentation that says "to create a new thing here are all the steps across all this silliness from start to finish". Is there a reason why this is process is so convoluted and unwieldy?

    24 Jun 2015
    1. User avatar

      Juan Felipe Cardona

      Once you understand it you will really appreciate it.

      24 Jun 2015
      1. User avatar

        Antigone K

        so ... kinda like being a brain surgeon? (wink)

        Yes, I get that it's very powerful and all that, but it just seems that it's a lot harder than it needs be. I've worked with a lot of databases and platforms, and all these schemes, associations, and such are a maze, at best. Even if it is something one appreciates once it's understood, it would be wonderful if someone who understood it would actually write out something like, "if you're creating a new screen for your project, follow these steps".

        24 Jun 2015
        1. User avatar

          Juan Felipe Cardona

          You could probably create a support ticket with Atlassian Support with your question and they might even surprise you with a link with just the information you need.

          24 Jun 2015
          1. User avatar

            Antigone K

            LOL! Yep, they sent me to this exact article (wink)

            25 Jun 2015
            1. User avatar

              Juan Felipe Cardona

              No way!... ok... My approach, in terms of the diagram in this page, is to go from bottom to top. That has worked well for me.

              26 Jun 2015
Powered by Confluence and Scroll Viewport