While many other software systems provide users with limited control over the presentation of screens, JIRA is very flexible when it comes to screen customizations. You can create your own screens and decide what fields are to be placed on them and their orders. You can also decide which screens are to be displayed for major issue operations. In JIRA, you can create and design customized screens for the following operations:
Screens are maintained centrally from the administration console, which means you need to be a JIRA administrator to create and configure screens. Perform the following steps to access the View Screens page:
The View Screens page lists all the screens that are currently available in your JIRA instance. You can select a screen and configure what fields will be on this screen and decide how you can divide a screen into various tabs.
For each of the screens listed here, JIRA will also tell you what screen scheme each of the screens are a part of and the workflows that are being used. You have probably noticed that for screens that are either part of a screen scheme or workflow, there is no Delete option available, as you cannot delete screens that are in use. You need to disassociate the screen from screen schemes and/or workflows to delete them, as shown in the following screenshot:
As shown in the preceding screenshot, for each screen you can perform the following operations:
Screens listed here do not affect JIRA Service Desk. We will cover screens and fields configuration for JIRA Service Desk in Chapter 11, JIRA Service Desk.
JIRA comes with three screens by default (listed here), and, every time you create a new project, a new set of screens is created for the project, based on the template you select. These project-specific screens will all have their names starting with the project key, for example, HD: Task Management View Issue Screen
, where HD
is the project's key.
While the default screens and screens automatically created for your projects are able to cover the most basic requirements, you will soon find yourself outgrowing them, and adjustments will need to be made. For example, if you want to keep certain fields read-only, such as priority, so that they cannot be changed after issue creation, you can achieve this by setting up different screens for creating and editing issues. Another example will be to have different create and edit screens for different issue types, such as bug and task. In these cases, you will need to create your own screen in JIRA using the following steps:
HD: Bug Create Screen
, to indicate that it is the screen to create new bug issues for project HD.At this point, your new screen is blank with no fields in it. You will see in later sections how to add fields onto screens and put them to use.
You can edit existing screens to update their details to help keep your configurations up to date and consistent. Perform the following steps to edit a screen:
To delete an existing screen, it must not be used by any screen schemes or workflows. If it is associated with a screen scheme or workflow, you will not be able to delete it. You will need to undo the association first. Perform the following steps to delete a screen:
Screens can be complicated with many of fields ordered logically, so creating a new screen from scratch may not be the most efficient method if there is already a similar one available. Just like with many other entities in JIRA, you can make a copy of an existing screen, thus cutting down the time that would otherwise take you to re-add all the fields:
Creating a new screen is like getting a blank piece of paper; the fun part is to add and arrange the fields on the screen. Fields in JIRA are arranged and displayed from top to bottom in a single column. You have full control of what fields can be added and in what order they can be arranged.
The only exception to this is for the View screen. When you are viewing an issue, fields are grouped together by type. For example, user fields such as reporter and assignee are displayed together on the top right-hand side of the page. Also note that for built-in fields such as Summary and Issue type, even if you take them off the screen, they will still be displayed when viewing an issue. For these fields, you cannot change their position on the screen.
JIRA also allows you to break your screens into tabs or pages within a form, and you can do all of this within a single configuration page. It is this level of flexibility combined with a simplicity that makes JIRA a very powerful tool.
Perform the following steps to configure an existing screen:
On this page, you can do the following:
When you first create a screen, it is of little use. In order for screens to have items to present to the users, you must first add fields onto the screens:
Fields are added to the bottom of the list. You can reorder the list of fields by simply dragging them up and down.
Fields can be taken off from a screen completely. When a field is taken off, the field will not appear when the screen is presented to the users. There is a subtle difference between deleting a field from a screen and hiding it (discussed in the previous chapter). Although both actions will prevent the field from showing up, by removing the field, issues will not receive a value for that field when they are created. This becomes important when a field is configured to have a default value. When the field is removed, the issue will not have the default value for the field; while if the field is simply hidden, the default value will be applied.
You will also need to pay close attention when deleting fields off a screen, as there is no confirmation dialog. Make sure that you do not delete required fields, such as summary, from a screen used to create new issues. As seen in Chapter 4, Field Management, JIRA will prevent you from hiding fields that are marked as required, but JIRA does not prevent you from taking the required fields off the screen. Therefore, it is possible for you to end up in a situation where JIRA requires a value for a field that does not exist on the screen. This can lead to very confusing error messages for end users: