This chapter provides information on how to set scopes for a templates for easy maintenance.
A scope lets you decide which fields are copied from a template. It’s used during the process of creating new issues or applying a template to an existing issue. With a scope you can set which optional fields are copied.
When you install Issue Templates for Jira a default scope is created and it contains All fields except and Reporter.
By default, each newly created template uses the inherit option. New templates inherit the default scope set in the Scopes configuration, while child templates inherit their scope from the parent.
It’s best to set a scope in your primary templates and linked issues, as they don’t inherit scope by default. Remove the reporter from the default scope as it overwrites the reporter of an issue with the one defined in a template.
There are three types of scopes that you can configure:
These are scopes that are applied globally to all templates by default (unless specified otherwise in a project).
These are scopes that are applied to templates in a specific project.
These are scopes that are specifically selected for a template. It’s either the inherit option or one of the global or project scopes.
To add a field to a scope:
Result
The selected fields have been added to the scope. You can delete fields by clicking X.
Newly created templates are configured to inherit a scope. For a primary template and linked issues, there is no parent to inherit a scope from. If a scope is not explicitly set, then the default scope is used. In configuration, you can choose one of your scopes and set it as default at any time. One of the configured scopes is a default scope.
You can set a default scope both in global and project configuration. Default scope overrides global scope.
Steps
To set which scope is default:
Result
Your scope has been set as the default one.
After the app is installed for the first time, the default scope is created automatically and it is configured to copy: All fields except Reporter.
Using these options is especially beneficial when your template is dynamically changing. For example, in a complex template that might need new custom fields in the future.
Use the All fields option to copy all non-empty fields from the template’s issue. In some scenarios, you might not want to copy all fields, especially summary and reporter when applying a template, in such cases use the All fields except option. It’s much easier to maintain a template this way.
Setting a scope with the inherit option is especially useful when you create epics with many stories and subtasks, and you need the same scope for the whole issue hierarchy. For the primary template or if a scope can’t be inherited, the default scope will be used, however, by default, a new template is configured to inherit a scope.
If all your templates in a hierarchy should use the same set of fields, you can configure each of them to inherit the scope. In most cases you won’t need to change anything, because newly created templates are configured to use this option.
With that, you can easily change the scope for the whole hierarchy by just changing the scope in your primary template.
All child templates with the inherit option will use the same scope as in their parents.
Scope inheritance doesn’t work for linked issues, therefore you should explicitly set the scope in each one of them, the default scope will be used otherwise.
You can add Sprint field to the scope. The Sprint ID will be copied, so that the template and new issue will share the sprint.
With default Board settings this configuration works well as issues are displayed only from one project. If you modify the JQL filter by deleting project clause, you will see all issues within one Sprint (including templates).
If you copy an active sprint, it will also be displayed as active sprint in the target project. However, right now it’s not possible to copy sprint and make it active (if it is not already active in the repository). You also can’t add issues to currently active sprint.
This solution has its pros and cons. If you close sprint in one project, then it will be closed in second project as well. It may be problematic in case of using it in more than one project.
If you copy an active sprint to a project where you already have an active one, it will be duplicated. As a result, you will have two open, active sprints. Due to Jira’s technical limitations you won’t be able to close any of them (button Complete Sprint is greyed out).
Managing Epic structure also may be problematic. Whenever you want to create a new sprint, you need to change the Sprint field in your templates.
Consider all the pros and cons before adding the Sprint field to your scope.
