- Get started
- About
- First steps
- Glossary
- Migration
- Configuration
- Global configuration
- Repository
- Template configuration
- Template scope
- Manage templates
- Supported fields
- Permissions
- Using templates
- Create issue from template
- Create issue structures
- Apply template to existing issue
- Recreate issue
- Use template custom field on issue create screen
- Default templates
- Direct link
- JQL searchers
- Variables
- Static variables
- Dynamic variables
- Smart defaults
- Basics
- Smart issues
- Smart users
- Smart dates
- Smart project
- How to use smart defaults
- App Integrations
- Team-managed projects
- Jira Software
- Jira Service Management
- Advanced Roadmaps
- Issue Checklist for Jira
- Advanced
- Automation
- Legacy automation action
- REST API
- Create issue and apply template with Jira REST API
- Security
- Security statement
- App permissions
Smart defaults - introduction
This chapter provides basic information about Smart defaults and Smart expressions used in templates.
The Issue Templates for Jira app provides additional Smart defaults tab available in templates (on the right side of the Issue View, in Issue Glance). The Smart defaults tab provides a Select, where you can find all fields supported in your project.
From now on, you can edit template fields and fill them with the smart expressions. Thanks to that, you are able to easily access data within Jira.
This chapter is divided into four sections:
How to access issue fields?
You can use the following methods to access issue fields:
issue
- will access a field for which it is configured
issue.fix_versions
- provide short form of field name with _ instead of space in case you want to configure it for other field e.g. Affects Versions
issue.field("Fix versions")
- use field expression with an exact name if your field contains special characters
issue.customfield_10330
- use custom field key in case you have more than 1 field with the same name
Example
If the Fix Versions field is set to 1.0.2 and 1.0.3 versions:
issue.field("Fix versions")
// returns
1.0.2, 1.0.3
Inherit Values
By using the parent
expression, you can easily configure nested (child) templates to inherit values provided in the parent.
This can be useful when you need to set the same component, version or labels in all epic’s issues and want to use the same template in different scenarios.
Just enter a field value in the Create issue dialog. All children created from the primary template will inherit the given value.
Pass the values to linked issues
To use the parent
accessor issues need to be in a parent-child relation, for example children of an epic or sub-tasks. Linked issues don’t have such a relation.
If you want to pass down values from your primary issue (issue from which the templating process starts), you can use the primaryIssue
accessor.
Example
primaryIssue
- will access a field for which it is configured
primaryIssue.fix_versions
- provides a short form of a field name with _
instead of space in case you want to configure it for other field, for example, Affects Versions
primaryIssue.field("Fix versions")
- use a field expression with an exact name if your field contains special characters
primaryIssue.customfield_10330
- use a custom field key in case you have more than 1 field with the same name
Fill in the field using dynamic variable
With the expression variable("variable name")
you can use values provided with dynamic variables in custom/system fields. You can reference variables in all children and linked issues.
This can be useful when you want to set the same value across the whole structure, and at the same time you want to use variables for the same value in different fields, for example as a part of a summary or description. This approach is much more flexible than using a simple parent expression.
Supported actions:
- assigning a user provided with
:user
type dynamic variable, all user type fields are supported, for example, assignee, reporter, user pickers - passing a
:date
or:datetime
variable to a date or a datetime field type, for example, Due date, Start date, Date Picker, Date Time Picker, etc. - setting priority, components, versions, custom selects (single & multi) from select variables
Set relative dates
With a now + 5d
expression you can set a relative date in date type fields. +5d
or -5d
is a shortcut for .plusBusinessDays(5)
or .minusBusinessDays(5)
.
As a source of the date you can use now
, issue properties like issue.created
, other date fields or inherited fields, for example, parent.due_date
.
Supported syntax:
[date] [+-] [dw]
d - business days, w - business weeks[date].plus[unit]
[date].miunus[unit]
Supported units:
- Days
- BusinessDays
- Weeks
- Months
- Quarters
- Years
- Millis
- Seconds
- Minutes
- Hours
Supported actions:
- Set a date relative to current time, for example:
now + 5d now.plusDays(3)
- Set a date relative to other issue field or property, for example:
issue.created + 5d issue.due_date.minusDays(2)
- Set relative dates based on parent date field, for example:
parent.due_date + 5d
- Set a date relative to :date variable, for example:
variable("Launch date") + 5d
Compute the field value when using templates
Value of any field can be computed using vast smart expressions.
Expressions that can be used depend on the type of field against which you are calculating the value, for example, a user field, like reporter, can be set to project lead by the project.lead
expression.
Example
Setting a reporter to the project lead: project.lead