Atlassian Jira Administrator ACP-100 – Introduction and the Jira Atmosphere

6. How to Create Screen Schemes

Screen schemes map the screens a user sees when they perform an issue operation. Before we start talking about how to create screen schemes, let’s talk about issue operations. Issue operations are actions a user takes when working with an issue. They include Create, when a user creates a brand new issue, edit when a user edits an existing issue, and View, when a user views an existing issue. In Jira, when you create, edit, or view an issue, you see a specific screen.

As the Jira admin, you pair the screen that shows up for each of these issue operations in the screen scheme. You then use that screen scheme for one or many projects. Your screen schemes provide the association of screen to issue operation in your project. For example, you can decide to show one screen when someone creates an issue, a different one when they edit, and another when they view. Or you could combine Edit and View, which is done in some default screen schemes.

Screen schemes allow you to show the right screen at the right time. They also allow you to control when someone can edit a field. For example, you can include a field on a Create screen and a View screen, but remove it from an edit screen, thus preventing a user from editing the field after they create the issue.

What are some of the situations where you might use a different screen for each issue operation? Like other schemes in Jira, each project template comes with a set of default screen schemes that map screens to issue operations. Which default screen scheme your project uses depends on the project template. For Jira core projects, you get two screens a Create screen and an Edit and View screen. For Jira software, things are a bit different.

You have the same Create, Edit, and View screen for most issues, the difference being the bug issue type uses a different screen than all other issue types. You handle this configuration of Issue type to screen scheme through the Issue Type screen scheme, which we talk about in another video. And if you need, you can customize these default screen schemes to have different screens, show at different issue operations, or you can create your own from scratch.

Just remember to include the appropriate fields on a Create screen so you don’t prevent users from submitting an issue. At Great Adventure, Violet wants to create a new screen scheme for business projects. This scheme includes a screen for the Create issue operation and another for the edit and view issue operations. Once created, she can share this scheme with other projects. This setup is similar to the default screen scheme for business projects, but Violet uses her custom screen for the Create Issue operation. First, navigate to the screen schemes page and when there, click Add screen Scheme.

On the next window, add a name and description for your new screen scheme. We call ours Business Screen Scheme and add a description next select the default screen to display and click Add. As the note shows, this default screen is for all unmapped issue operations in the scheme. For great adventure, we choose the default screen. Next, we need to associate the other issue operations with the appropriate screens. We’re continuing this demonstration from creating a new screen scheme.

If you need to edit an existing screen, go to the Screen Schemes page in Jira Administration and click Configure. Under the Actions menu, on the Configure screen scheme page, click Associate an Issue operation with a screen. In the window, select the Issue operation you want to associate with the screen.

For example, we select Create Issue. In the next screen menu, select the screen you want to associate with the Issue operation, and then click Add file. It needs to associate the create issue issue operation with the business. Create issue screen. Once you associate the issue operation with a screen, you see that relationship listed on the screen scheme page. Any unmapped issue operations use the default you select when you first create a screen scheme.

7. How to Create Issue Type Screen Schemes

Issue type Screen Schemes map screen schemes to Issue types so they can display different screens to capture required data. So how do screens, screen schemes, and Issue type screen schemes all relate? When a user performs an operation interior like Create, Edit, or view an issue, they see a screen. Screens present fields. You manage field visibility through field configuration and configuration of your screen. We talk more about field configuration in another video for now. Remember, you can remove a field from a screen and not destroy its data. Screen schemes map screens to issue operations.

For example, selecting the Business Create Issue Screen for the Create Issue Operation means users will see that screen whenever they create an issue. Issue type Screen Schemes map screen schemes to specific issue types. For example, Violet Maps, the evaluation event and person issue types to the business screen scheme. So whenever a user creates, edits, or views one of those Issue types, they will see the screens dictated by the Business Screen scheme.

With Issue Type screen Schemes, you can collect information for different issue types by presenting the right screen at the right time for that issue type. If you need to have users fill out one set of fields for one issue type and another for a different issue type, you should use an Issue type screen scheme. For example, Violet is building a set of schemes she plans to share across business projects at Great Adventure. She knows that several departments need the Business screen scheme for certain issue types so they can collect data on the user’s role, department, and line manager.

She already added those fields to the appropriate screen and mapped that screen to the Create Issue operation. Think about your Jira instance and projects. Would any projects benefit from using Issue type screen schemes to capture different information on issues? To get started with a new Issue type screen scheme, navigate to the Issue Type Screen Schemes page.

When there, click Add Issue Type Screen Scheme in the window, enter the name and description for your new scheme, and Violet uses Business Issue Type Screen Scheme with a description. Then, in the Screen Scheme menu, select the default Screen scheme for all unmapped Issue types and click Add. Violet uses the Process Management Screen scheme for the default next, configure the Issue Type Screen scheme to map screen schemes to Issue types. On the configure issue type screen scheme page click.

Associate an issue type with the screen scheme. On the window that opens, select an Issue type and a screen scheme to Associate, and then click Add. Violet needs to associate the Event Issue type with the Business Screen scheme. Add more Issue types as needed. For now, let’s associate the new Issue Type screen scheme with a project. First navigate to your project. Then in project settings, click Screens from the left menu. On the Screens page, under Actions, click Use a different scheme. You see the Issue Type Screen Scheme association page from the scheme menu, select the new scheme for the project and click Associate Needs to use the Business Issue type screen scheme. When you finish, you should see the screens page in Project Settings with your new scheme in place.

8. How to Set Field Configuration

Jira includes custom fields and system fields. You can set the behavior of a field through field configuration, determining what fields are required or even visible. You use Field configuration in a field configuration scheme to map to issue types. All Jira projects use the default field configuration until you create and apply a custom field configuration. You must map field configurations to issue types using a field type configuration scheme, or those settings won’t apply to any projects.

In Field Configuration, you can hide fields that you don’t want to appear. The field exists in Jira, but you can’t add it to screens. The field data also disappears from search results and issue filters unless you make the field visible. Again, you may want to hide a field in one set of projects, but show that field in others. For example, you might hide the Story Points field in projects that don’t use story points.

And note that while you can use Issue Level Security to hide issues in Jira, you can’t hide fields from specific users out of the box. However, with script runner for Jira, you can implement field level security using behaviors. Learn more in the Getting Started with ScriptRunner for Jira course. Deleting a field entirely removes the field and all of its data from your instance. Also, deleting a field clears its values from the database. Before deleting a field, we recommend that you back up your instance. That way, if you need to access the data later, you can restore it locally. You may want to delete a test field or one you know you don’t need anymore.

For example, perhaps you captured data in a custom field, but you decided to use a system field later. Removing a field from a screen takes it off one particular screen, but you can still use it in others. This option does not delete any field data. You may want to remove a field from one screen for a particular issue operation, but make it available for another screen and issue operation.

For example, you may want to remove the Due date field from the Edit screen, but leave it on the Create and View screens. If you delete a field and need to migrate data to a new field type, you can use the Bulk Change feature in Jira to update Issues data.

However, this function is limited, so you may consider using Script Runner for Jira, which provides more advanced migration of data between different field types. In Field Configuration, you can set a field as required or optional. When one of your users requests to make a field required, make sure they really need it.

Let them know that while they’ll get data, that data might not be usable. Why? When you use required fields, your users have to complete the field so you get data. However, those users may not know how to complete the field accurately, so it could be bad data or plain incorrect. We advise you to use required fields only when absolutely necessary. Also, any required field must be on the Create screen of the issue or the user won’t be able to create issues at all since they didn’t complete the required fields. If a user asked you to make the due date field required, what would you do? Do you currently have any fields in your instance that you could make optional? Violet needs to make the Line Manager Field required and hide Time tracking in a new field configuration for business projects. She’ll later associate this field configuration in a Business field configuration scheme.

Navigate to the field configurations page and locate the default field configuration next to default field configuration. Under actions, click copy. On the next page, add a name and description for your field configuration, and then click Copy. And for greater adventure, Violet needs to call this Business Field Configuration and she adds a description. You see the new configuration listed on the View Field Configurations page. And from here, you add the field configuration to a field configuration scheme for it to take effect. First, let’s walk through the process of configuring fields. Once you create your field configuration, you set the actual behaviors of the fields and remember that field configuration hides fields and their data from projects using the configuration in their field configuration scheme. Violet sets the Time Tracking field as hidden. And once you hide a field, the only option available for the field is Show. She also sets the line manager field as required. Once you set a field to Required, you have the option to make it optional again later.