Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

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

 

 

  • No labels

17 Comments

  1. Hi,

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

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

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

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

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

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

     

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

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

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

      1. Anonymous

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

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

     

     

     

  7. Hello

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

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

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

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

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

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