Purpose

Post-function "Create issues and subtasks" allows you to automatically create one or multiple new issues and sub-tasks when executing a transition in your workflows. You can also set the fields of the new issues based on the values of fields in other issues, and link the new issues to the other issues in your Jira instance.

Dynamic issue type selection

StatuscolourYellowtitleSince Version 2.4.0

• Create multiple issues (with various issue types) in a single post function
• Dynamically inherit the issue type from the issue firing the transition 
• Create both standard and sub-task issue types

Image Removed

Example: Make Epic issues create automatically 3 Stories when executing a certain transition

In this example we show how to implement a post-function in the workflow of of Epic issues issues in order to automatically create 3 Stories with the following summaries: 'GUI Design', 'Business Logic' and 'Data Model'.

Description of the behavior configured

The 3 new new stories that that will be created will have the following characteristics:

• Project: the project where the stories are going to be created is the same as current issue, i.e., the the Epic.

• Summary: will take the value of the the seed string, i.e., "GUI Design", "Business Logic" and "Data Model". To do it we use string expression expression ^%, which is simply the value of the seed string.

• Description: we have a different description per each new story:
  • Story created by seed "GUI Design": "Design and implementation of the GUI for the Epic."
  • Story created by seed "Business Logic": "Implementation of the business logic for the Epic issue."
  • Story created by seed "Data Model": "Design and implementation of the data model for the Epic."  
    We use the following string expression:
    getMatchingValue(^%, ["GUI Design", "Business Logic", "Data Model"], ["Design and implementation of the GUI for the Epic.", "Implementation of the business logic for the Epic issue.", "Design and implementation of the data model for the Epic."])

• Set Fields: we set the following fields in the new story:
  • Assignee: we assign each issue to a different user. To do it we write the the name of a project role, or a a user name  (not to be confused with user's full name). In case we use a project role, we previously should have have set the default user for each project role in each project.
    We use the following string expression:   getMatchingValue(^%, ["GUI Design", "Business Logic", "Data Model"], ["GUI Designer", "Logic Analyst", "Data Architect"]), where where "GUI Designer",  "Logic Analyst" and  and "Data Architect" are are project role names.
  • Reporter: we use use current user as as value for setting the reporter. Current user is the user who is triggering the transition where the post-function is being executed.
  • Components: we set field field Components with with different values per each new story.
    We use the following string expression:   getMatchingValue(^%, ["GUI Design", "Business Logic", "Data Model"], ["GUI", "Business Core, Auxiliary Elements", "Data Base, Data Persistency"])
  • Epic Link: we set set Epic Link to to the value of of Epic Name in in current issue, which is an an Epic. This way we are linking each new story with its epic. If we were executing the post-function from a a story, we would have to use field field Epic Link as as value, this way we would be making a a story to to create a new new sibling story.
  • Execute Transition: we write the name of transition "Start Progress", this way we are moving the new stories to status status In Progress just just after issue creation. We can write into this field more than once, making the new issue to sequentially execute several transitions in its workflow.
  • New comment: we create a comment in each new issue with a dynamic text using basic parsing mode, where field codes are replaced with their values at runtime. 
    We use the following text:   This issue was created automatically from epic "%{12511}" on %{00057}..
  • New watchers: we use the following string expression for obtaining the list of users who are watching issues blocked by the the Epic: (toString(fieldValue(%{00133}, linkedIssues("blocks")))), and this way all those users become watchers of the new stories. Note that that %{00133} is is field codes for for Watchers.

• Inherit Remaining Fields: fields not set in section section Set Fields will will inherit the values of the same fields in the the Epic issue issue.

• Issue Links: each new story will be linked using "blocks" issue link type, to all the issues blocked by its its Epic. This way we are creating a direct blocking relation where there was only an indirect one (through the epic).

• Conditional execution: we set a condition in order to ensure that the post-function is only executed when current issue is an an Epic, this way we can use the post-function in workflows shared with other issue types.

Image AddedImage Removed
Image Removed Image Added
Image Removed Image Added

Once configured, transition will look like this:

Image RemovedImage Added

Screenshots showing an example of execution of the post-function 

Configuration Parameters

Issues to be created

Specifies whether we want to create create only one issue issue, or or multiple issues. In case of multiple issues we use use one seed for each new issue. We should use one of 3 different kinds of seeds:

• Seed issues: we use existing issues as seeds for the new issues. We have 2 different methods to select out seeds issues:
  • JQL Query: a new issue will be created per each issue returned by a a JQL Query.
  • Issue List: a new issue will be created per each issue returned by an Issue List expressions. Fields in seed issues can be referenced using prefix prefix ^ in in field codes. Example: Create a Subtask in each Story of an Epic.
• Seed strings: a new issue will be created per each string returned by a a String List expressions. This is the method used in the previous example. Seed string can be referenced using using ^% when when setting fields or issue links for the new issue. The usage example described above, and these others 3 ones use seed strings:   Create a Story for each Component in Epic,  Create a sub-task for each user selected in a Multi-User Picker and  and Create specific sub-tasks for each selected component.
• Seed numbers: we use a a Math-Time expressions  (can be a literal number) for specifying the number of issues to be created. Seed number (i.e., number of creation order starting by 1) can be referenced using using ^ when when setting fields or issue links for the new issue. Example: Create 3 issues in 3 different projects.

Issue Type

This parameter specifies the issue type of the new issues or subtasks. When selecting selecting Story you you will have to set field field Epic Link in in order to set the relationship with with Epic, like shown in the previous usage example.

Project

This parameter is unavailable for sub-tasks, since they have to belong to the same project as their parent issue. There are 4 methods of specifying the project:

• Current Project: the project of the current issue, i.e., the issue that is executing the post-function.
• Selected Project: we use a dropdown list for selecting a project among those present in the JIRA instance.
• Seed Issue's Project: the project of the seed issue which is causing the issue creation. This option is only available when creating multiple issues based on seed issues.
• Project Key: a a string expression that that returns a a project key. This method is typically used for specifying different a project for each new issue. In the previous example we could have used something like:
  getMatchingValue(^%, ["GUI Design", "Business Logic", "Data Model"], ["CRM", "HKV", "PKT"]), where where CRM, HKV and  HKV and PKT are are project keys.

Parent Issue

This parameter is available only for creation of sub-tasks, i.e., when the issue type selected in parameter parameter Issue Type is is a sub-task. There are 6 methods for selecting the parent issue:

• Current Issue: the issue that is executing the post-function. It only makes sense when current issue is not a sub-task itself.
• Parent of Current Issue: the parent of the issue that is executing the post-function, which obviously should be a sub-task. With this option we are creating a a sibling sub-task.
• Seed Issue: seed issue which is causing the issue creation. It makes sense when seed issue is not a sub-task itself.
• JQL Query: we use a JQL query for returning an issue that will be the parent of the sub-task that will be created. If the JQL query returns more than one issue, the first one which isn't a sub-task will be used.
• Issue List: we use an an Issue List expressions for for selecting the parent issue. If more than one issue is returned, then the first non-sub-task will be used.
• Issue Key: a a string expression will will be used for returning the issue key of the parent. We could use something like like "CRM-23" for for using a fixed issue. In the previous example, we could have used the following string expression for selecting different parents for each new issue:   getMatchingValue(^%, ["GUI Design", "Business Logic", "Data Model"], ["CRM-23", "CRM-24", "CRM-25"]).

Summary

We set the summary of the new issues. We can use two different parsing modes:

• Basic: field codes with format format %{nnnnn} can can be inserted among the text. The field codes will be replaced with their corresponding field values at run time.
• Advanced: we use a a string expression for for setting the summary. In this mode we can insert references to seeds (seed string string ^%, or seed number number ^), or field values on seed issues (format format ^%{nnnnn} and  and ^{nnnnn}). We use the the Expression Parser implemented implemented by the plugin.

Description

We set the description of the new issues. We can use two different parsing modes:

• Basic: field codes with format format %{nnnnn} can can be inserted among the text. The field codes will be replaced with their corresponding field values at runtime.
• Advanced: we use a a string expression for for setting the summary. In this mode we can insert references to seeds (seed string string ^%, or seed number number ^), or field values on seed issues (format format ^%{nnnnn} and  and ^{nnnnn}). We use the the Expression Parser implemented implemented by the plugin.

Set Fields

This section is used for setting fields in the new issues, including including Assignee,   Reporter,   Epic Link, etc.

Depending on the the field type we can use different methods for specifying the value of the fields.

Post-function Create Issues and Sub-tasks allows many different ways for assigning the newly created issues. These are some examples:

Inherit values for remaining fields

Optionally we can inherit field values for the fields whose values have not been set in section section Set Fields. There are 5 different options for selecting the issue the values will be inherited from:

• Current Issue: the the issue that is executing the post-function.
• Seed Issue: seed seed issue which is causing the issue creation. This method is only available when creating multiple issues based on seed issues.
• Parent of Current Issue: the the parent of the issue that is executing the post-function. This method only makes sense when current issue is a sub-task.
• Parent of New Sub-task: the the parent of the new sub-task. This method is only available when the issue type of the new issue is a sub-task.
• Epic of Current Issue: the the epic of current issue. If current issue is a sub-task and hasn't t Epic Link set set, then the epic of its parent will be used.

Issue Links

This section is used for specifying issue links to be created between new issues and other issues in the Jira instance. We can set as many issue links as we need, specifying an an issue link type and and a set of of issues to be linked. There are 7 different methods to define the issues to be linked:

• Current Issue: the the issue that is executing the post-function.
• Seed Issue: seed seed issue which is causing the issue creation. This method is only available when creating multiple issues based on seed issues.
• Parent of Current Issue: the the parent of the issue that is executing the post-function. This method only makes sense when current issue is a sub-task.
• Parent of New Sub-task: the the parent of the new sub-task. This method is only available when the issue type of the new issue is a sub-task.
• JQL Query: we use a JQL query for selecting a set of issues that will be the linked to each new issue, using the issue link type previously selected.
• Issue List: we use an an Issue List expressions for for selecting a set of issues that will be the linked to each new issue, using the issue link type previously selected.

Additional actions

Optional actions to be carried out once all the new issues have been created. Currently there is only one available action:

• Save issue keys of of created issues into into Ephemeral String 3 virtual virtual field as a comma separated list:
  Adds a comma separated list of issue keys at the end of the current value of of Ephemeral String 3, this way we can accumulate in this field all the issues created in subsequent executions of post-function Create issues and sub-tasks within a same post-function. Then we can use this value in another post-function, e.g. sending an email, or creating a comment.

Conditional execution

The post-function will be executed only when the boolean expression entered in this parameter is true, otherwise nothing will happen. You can make your boolean expression depend on the values of one or more fields, issue links, sub-tasks, etc. Use the syntax defined by the the Expression Parser.