An information system such as Atlassian JIRA is only as useful as the data that goes into it, so it is no surprise that JIRA is very flexible when it comes to letting you customize the fields and screens.

JIRA comes with a suite of default fields to help you get it up and running quickly, and it also allows you to add your own fields, called custom fields, to address your unique needs.

In this chapter, we will learn not only about how to create these custom fields in JIRA, but also the different behaviors that these fields can have. We will end the chapter by showing you an example of expanding the types of custom fields you can have with third-party add-ons and using scripts to create your own field logic.

As mentioned before, one of the key features of JIRA is its ability to let you customize the fields in which you have to collect information from the user. JIRA comes with over 20 different types of custom fields, such as simple text and select lists.

In this recipe, we will be creating a new custom field—a single select list custom field—from the default selection.

Often, it is useful for custom fields to have different values depending on the selected project and issue type combination. A good example would be for a select list custom field to show different sets of options for different projects.

We will look at how to achieve this with a custom field configuration scheme, also known as context. A custom field configuration scheme controls what data the custom field will display, such as the field's default value and select options. Just like all other configuration schemes in JIRA, the custom field configuration scheme is applied on a project and issue type context.

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 users will 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 behaviors of a field; these include the field's mandatory requirements, visibility, renderer, and description.

By default, the assignee field has an unassigned option, which is equivalent to making the field optional. If you went to check out field configuration, you would have realized that you could not 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 the assignee a required field.

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

Most custom field types, such as select lists and text fields, can be rendered in multiple ways. For example, select lists can be rendered either with an autocomplete feature or as a simple, standard drop-down list.

In this recipe, we will be changing the environment field to use Wiki Style Renderer so that we can use wiki markup when entering data.

As we have seen in previous recipes, you can configure a field's behaviors 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 Task issue type.