As mentioned above, this process is a little long-winded so it’s really important that you have a good plan and you are prepared to spend the time required to do it properly. You don’t have to make all the changes at once but it’s quite likely that it will make sense to do so and since it’s going to take some time, i’d suggest you plan ahead and find a time where you can do it all in one go.
I recommend that you first read through this list of steps from the beginning to the end before you start (as one or two of them should happen in a different order depending on your circumstances – I’ve indicated this in the step’s instructions) and write-down (or type-up) your own set of steps to work from. You may also want to take some of the steps you don’t understand as much and read the Jira documentation for that specific step.
Perhaps more importantly, you should map out all of the changes you are planning to make in advance as you don’t want to be making decisions about what fields you want in a given issue type in the middle of configuring Jira in the backend. Sit down with you team and work out which fields you don’t need from the current Issue Types available and capture any new fields you’d like to introduce.
Issues are the items you create in Jira. A ‘User Story’ is one type of Issue, a ‘Bug’ is another…
You may not actually need to do this step. Every Project in Jira is automatically set up with the Default Issue Type Scheme which has all of the Default Issue Types associated with it already. If you are starting a new Project, take a look at the existing Issue Types and if the names of all of these Issue Types suits your needs, you’re better off just sticking with these Issue Types.
You can’t create new Issue Types with the same name as existing Issue Types and creating new Issue Types that are almost identical to existing ones just clutters the Jira Admin screens. New Issue Types are also added to the Default Issue Type Scheme which means that any project that hasn’t been associated with a custom Issue Type Scheme will have this new Issue Type available to all of the users of that Project whenever they click the ‘Create’ button which can be very annoying for your colleagues.
How to do it:
- Navigate to the Jira Administration > Issues
- Select Issue Types from the left pane and click the ‘Add Issue Type’ button
- Add details to the ‘Name’ and ‘Description’ fields, select the ‘Issue Type’ and the image you want to represent the Issue Type on your boards
- Click the ‘Add’ button
That’s all you need to do to create a new Issue Type. You can easily edit the Issue Type you have just created at any time and you can delete the Issue Types you create so they aren’t set in stone forever but once you’ve created issues of a particular Issue Type, you will need an Issue Type to migrate those issues to and you could have issues with your workflows. I’m not going to cover Workflows in this post so just understand, deleting a new Issue Type you just created is not a problem but deleting an existing Issue Type that other Projects might be using could be extremely problematic.
An Issue Type Scheme is basically just a virtual grouping of Issue Types. Instead of associating individual Issue Types with Projects in Jira, you associate them with an Issue Type Scheme and associate that scheme with a project (or multiple projects).
Issue Types can be associated with multiple Issue Type Schemes and so if you edit an Issue Type (change it’s description or delete it for example) then these changes will be reflected in all of the Issue Type Schemes that the Issue Type is associated with and subsequently reflected in all of the Projects that have those Issue Type Schemes associated to them.
That makes it sound like all the changes you make are going to have a wide impact but in reality, its this grouping that allows you to add and remove Issue Types from your Project without affecting every other Project on your company’s instance of Jira.
As soon as you have created an Issue Type Scheme and Associated it with your Project (Step 4) you are able to change the Issue Types available to your team without affecting the rest of your organisation.
How to do it:
- Navigate to the Jira Administration > Issues
- Select Issue Type Schemes from the left pane and click the ‘Add Issue Type Scheme’ button
- Add details to the ‘Scheme Name’ and ‘Description’ fields, and select the ‘Default Issue Type’ (the Issue Type you want to selected by default when you create a new issue on your backlog)
- Drag the Issue Types you want from the list on the right into the list on the left
- Reorder the Issue Types into the order that you want them to appear on the drop-down when you are creating new issues on your backlog
- Click the ‘Save’ button at the bottom of the page
This is the step where you tell Jira which Issue Types you want to be available in your Project.
The step itself is quite a straight-forward but you first need to think about when you are going to perform it. If you are setting everything up from scratch and you have a new Project with no issues raised yet then it doesn’t matter when you do this. If you already have issues raised on your Project’s backlog then you will need to make sure that there is an Issue Type in your new Issue Type scheme that these issues can be converted to with the Issue Type Migration Wizard. The wizard will guid you through the process of migrating issues from one Issue Type to another and it only takes a few clicks.
Since you have not configured any of the field behaviours yet, you also need to think about how appropriate the Issue Types you are migrating to are at this point. Basically, if you have created new Issue Types and you are migrating existing issues to these new types, you might want to wait until you have been through the Field Configuration steps below.
You can complete this step from the Jira Global Administration pages or from your Project’s Administration pages. If you are making this change at the end of the process along with the changes to Field Configurations and Screens then you might find it easier to use the Project Administration page as all the links are in one place. The steps below show you how to do it from the Jira Global Administration Page since that’s where you would be in the the system if you performed the step at this point in the process.
How to do it:
- Navigate to the Jira Administration > Issues
- Select Issue Type Schemes from the left pane and find the Issue Type Scheme you just created in the list
- click the ‘Associate’ link in the ‘Operations’ column for your Issue Type Scheme
- Select your Project(s) from the drop-down list
- Click the ‘Save’ button at the bottom of the page
Talking about migrating all of the issues in your backlog might sound like a scary process but its not really a huge deal. First of all, you can only affect the issues in your Project’s backlog when you are performing this step so you don’t need to worry about ruining everyone else’s day. Secondly, since you haven’t changed the Field Configurations yet, it is highly likely that you will be migrating issues from the default Issue Type Scheme to a new Issue Type Scheme that is simply a shortlist of the Default Issue Types at this stage meaning the migration is pretty straight forward.
In short, if you are just creating a new Issue Type Scheme that gets rid of the long list of Issue Types that your Project doesn’t use anyway then it should be a very quick and easy process.
Once you have done this step, you can test it is working by clicking the ‘Create’ button, selecting the Project you have associated with the new Issue Type Scheme and checking the Issue Types you see are the ones you selected for the scheme.
(Specify the Field Configuration Name and Description)
So far, you have created some new Issue Types, grouped them with an Issue Type Scheme and associated that scheme with a Project. This is the first step in customising the fields you see when creating or editing issues of each different Issue Type.
You might not need to do this step, or steps 6-9 if you are happy to use the Default Field Configuration you get with Standard Issue Types you have created or the existing Issue Types Field Configurations.
Conversely, you may decide that you are happy with the existing Issue Types and Issue Type Schemes but that you want to adjust the Fields Configurations for the Issues on your Project and so may skip steps 2-4 and start here. It’s worth pointing out here that if you skip steps 2-4 and just work on Field Configurations then whenever anyone later adds a new Issue Type to the Default Issue Type Scheme, that Issue Type will appear in the list of available Issue Types for your team to create which can be confusing for them and can cause problems later on if people create Issues of the wrong Issue Type.
For each of the Issue Types in your Project’s Issue Type Scheme that you want to customise, you need to create a Field Configuration.
How to do it:
- Navigate to Jira Administration > Field Configurations
- Click the ‘Add Field Configuration’ button
- Add details to the ‘Name’ and ‘Description’ fields
- Click the ‘Add’ button
Try to think carefully about the name and the description of the Field Configuration. As more and more administrators create Field Configurations, it will get more and more difficult to manage them and so naming them sensibly will reduce the risk of other administrators making a mistake that could affect your Project.
(Edit the Field Descriptions, Show/Hide fields, mark fields as required. Also manage the Renderers and Screens for this Field)
This is the step where you adjust the fields that are recorded for Issue Types associated with your new Field Configuration. You will set the field to show or hide, you will set the description and you will decide whether the field is required or not. You can also specify the format of certain types of fields using the ‘Renderers’ options. If you are changing a multi-line text field, you can specify whether this field is plain-text (Default Text Renderer) or rich-text (Wiki-Style Renderer). There are also options for the screens that these fields appear on which there is more information on later in this document.
How to do it:
After you click the ‘Add’ button as detailed in the previous step, you will automatically be taken to the ‘View Field Configuration’ screen where you can see all of the available fields and make your changes but if you are making changes to an existing Field Configuration, follow these steps:
- Navigate to Jira Administration > Field Configurations
- Find the Field Configuration you want to configure and click the ‘Configure’ link in the ‘Operations’ column
- To change a Field’s description (The line of text shown under the Field as the Issue is created) click the ‘Edit’ link
- To Show or Hide a Field’s click the ‘Show’ or the ‘Hide’ link
- To make a field mandatory, click the ‘Required’ link
- For multi-line text fields you can click the ‘Renderers’ link to chose between plain-text and rich-text
So long as you are changing the behaviours of a new Field Configuration you have created, you can be sure that you are not affecting anyone else’s Project. Each Field Configuration has the list of Field Configuration Schemes that it is associated with listed next to it so you should be able to determine the impact your changes could make but again, good names and descriptions for Field configurations and Field Configuration Screens is extremely useful for situations like this.
(Specify the Field Configuration Scheme Name and Description)
(Associate all of the Field Configurations you have created to the Issue Types you selected in your Issue Type Scheme)
Similar to step 3 you don’t need to do this til the end as you’ll want to have it all sorted first.
https://confluence.atlassian.com/jiracloud/re-indexing-after-major-configuration-changes-735940649.html
You can do it in the background so that the platform is available to everyone still
Leave a Reply