Jira comes with a number of issue types out of the box that are designed for software project management. However, over time, you might find that these issue types do not apply to all of your projects, and you have added your own. In this recipe, we will look at how to manage the issue types, so that each project can have its own set of issue types.

Proceed with the following steps to set up a project-specific issue type list:

1. Log into Jira with a user that has a Jira administrator's permission.
2. Navigate to Administration > Issues > Issue type schemes.
3. Click on the Add issue type scheme button.
4. Enter the name for the new issue type scheme.
5. Add issue...

Required fields such as Summary and Issue Type have a little red asterisk next to them, which means they must have a value when you are creating or updating an issue. This is a great way to ensure that users do not skip filling in important information.

We will look at how to make any fields of your choice required in this recipe, with field configurations. A field configuration controls the behavior of a field; this includes the field's mandatory requirements, visibility, renderer, and description.

Proceed with the following steps to make a field required in Jira:

1. Log into Jira with a user that has a Jira administrators permission.
2. Navigate to Administration > Issues > Field...

By default, the Assignee field has an unassigned option, which is equivalent to making the field optional. If you look at the field configuration, you will realize that you cannot make the Assignee field required, as there is no such option available.

In this recipe, we will look at how to disable the unassigned option, effectively making Assignee a required field.

Note the following conditions are required for your projects in order to disable the unassigned option for each individual project:

• Issues that are currently using that option for the Assignee field—you will need to change all issues with an Unassigned value for Assignee to something else.
• Projects that have...

There will be times when a field is no longer needed. When this happens, instead of deleting the field, which would also remove all its data, you can choose to hide it. If you need the field again further down the track, you can simply unhide it and retain all the data.

In this recipe, we will be hiding both the Priority and Due Date fields.

Proceed with the following steps to hide a field in Jira:

1. Log into Jira with a user that has a Jira administrator's permission.
2. Navigate to Administration > Issues > Field Configurations.
3. Click on the Configure link for the field configuration used by the project and issue type.
4. Click on the Hide link for Priority and Due Date.

You can configure a field's behavior with field configuration. Jira not only comes with a default field configuration that is applied to all project and issue types by default, but it also lets you create your own so that you can choose the projects and/or issue types to apply your field configuration to.

In this recipe, we will make the Description and Assignee fields required only for the Bug issue type.

Setting up a new field configuration is a three-step process. The first step is to create the new field configurations:

1. Log into Jira with a user that has a Jira administrator's permission.
2. Navigate to Administration > Issues > Field Configurations.
3. Click...

Jira comes with three screens by default—the Default screen, the Resolve Issue screen, and the Workflow screen.

In this recipe, we will look at how to create a new screen from scratch, and then make it appear when we are creating a new Task issue.

The screen is one of the most complicated configurations in Jira. To create a new screen and apply it often requires you to configure multiple schemes. So, we will break these steps into three logical groups.

Firstly, we need to create our new screen:

1. Log into Jira with a user that has a Jira administrator's permission.
2. Navigate to Administration > Issues > Screens.
3. Click on the Add Screen button and...

Custom field types such as select list (single and multi) come with the None option, and the only way to remove it is to make the field required. While this makes sense, it can be cumbersome to chase down every field and configuration.

In this recipe, we will remove the None option from all single select list custom fields.

Since we will be modifying physical files in Jira, you will want to take backups of the files we change.

Jira uses Velocity templates to render custom fields. These templates are...

Users who are new to Jira often find it confusing when it comes to filling in fields, especially custom fields. Therefore, it is for you as the administrator to provide useful tips and descriptions to explain what some of the fields are for.

In this recipe, we will be adding a help icon to a customer field that we have called Team. You can apply this recipe to any custom fields you have in your Jira.

Proceed with the following steps to add help tips to a custom field:

1. Log into Jira with a user that has a Jira administrator's permission.
2. Navigate to Administration > Issues > Custom Fields.
3. Click on the Edit link for the custom field.
4. Enter the following HTML snippet...

JavaScript can be used to manipulate the HTML of custom fields. By adding JavaScript code in the custom field description and wrapping the code in <script> tags, Jira will execute the code when the custom field is rendered.

In this recipe, we will look at another way of removing the None option from select list custom fields.

This recipe uses the jQuery JavaScript library, which is bundled with Jira. If you are not familiar with jQuery, you can find the documentation at http://jquery.com.

We will also need to use the custom field's ID in our script, so you will need to have that handy. You can find the ID by going to the Custom fields page, clicking on the Edit link...

As you add more and more fields onto your screens, sometimes it can be overwhelming and confusing for your end users, especially for free text fields such as Description. Users will often enter data however they like. To help with that, one way is to have instructions set as default values for some of these fields to help guide your users with their inputs. For those of you who have used other systems, such as GitHub, this is a common practice.

In this recipe, we will look at how to set up a default value for the Description field, in the form of instructions for users to follow when creating a bug report.

For this recipe, we need to have the ScriptRunner for Jira add-on installed...

Out of the box, Jira comes with several levels of permissions, starting at the system level and going down to the issue level, allowing you to control who should have access to issues. While this is usually sufficient, you will find yourself needing to apply permissions to individual fields. For example, you may want a field such as Description to be read-only for everyone, but only editable by a select group of users.

One option is to create your own custom field types, as described in the later recipe, and code the permission requirement as part of the field, but this approach requires programming and cannot be applied to fields that are not created by you.

In this recipe, we will look at an option to apply field-level permissions to both system fields and custom fields.

All custom fields that come out-of-the-box with Jira have predefined purposes, such as the text field, which allows users to type in some simple text. It will often be useful to have a specialized custom field that does exactly what you need. Unfortunately, this often requires custom development efforts.

However, there is an add-on that provides a custom field type that lets you use Groovy scripts to power its logic.

In this recipe, we will look at how to create a custom field that uses a Groovy script to display the total number of comments on any given issue.

For this recipe, we need to have the ScriptRunner for Jira add-on installed. You can download it from the following...