To add a 'Create/Clone issue' post-function to a transition:
Click Edit for the workflow that has the transition you wish to add the post-function on.
In the Workflow Designer, select the transition.
Click on Post Functions in the properties panel.
Click on Addpost function.
Select Create/Clone issue(s) from the list of post-functions.
Click on Add to add the post-function to the transition.
Select the Options provided to add the required parameters.
Click on Add to add the post-function to the transition.
Note that you need to publish the workflow for changes to be effective
When you add this post-function to a transition and trigger the transition, the add-on creates one or more new issue(s).
Project: Project in which the new issue(s) should be created.
Same as the current issue: Creates an issue in the same project as the current issue.
Calculated: Creates an issue in a project whose key is the value returned by a Groovy script.
Projects: Creates an issue in the project selected from the list of projects.
Issue type: Issue type of the newly created issue(s). When the issue type is Calculated, you can type a Groovy script that returns the issue type name or the numerical ID. See the Expected Value tab of the Groovy help editor or refer to the documentation to know more about the expected value.
Parent issue: When the issue type is Sub-task, you must specify its parent issue in the Parent issue field.
Current issue: The current issue will be the parent of the newly created issue.
Another issue: You can select the issue from one of the following options:
Start typing an issue key in the text box and you will be offered options based on your issue browsing history
[Select issue]: if you click on [Select Issue], an Issue selector window gets displayed. You can select the issue either from:
Recent Issues: Displays issues that you have recently viewed and first 50 issues from your current search or
From Filter: Displays issues of your saved searches.
Calculated: Type a Groovy script that returns a key which should be the parent of the newly created issue.
Note that when the issue type is:
Epic, you should set the Epic Name field with a value using the Set fields of new issue option (explained below).
Story, you might want to add the newly created story to an Epic. In that case, you should add the Epic link field with the key of the Epic as the value in the Set fields of new issue option (explained below).
Link to new issue
Links the newly created issue(s) to the current issue, with a link type selected from the list of link types. The default value is "is not linked to", which will not create any issue links.
Set fields of new issue
Sets the field values of the newly created issue(s). The Summary field is added by default since it is required for any issue type.
Mode: determines which set of fields should automatically be copied to the new issue(s)
Only copy or set fields listed below: by default, no field will be copied to the new issue, and you must explicitly add the fields that must be copied or set under the “Specific fields” section (see below)
Copy all fields that appear on the Create screen of the issue type to create, in the target project: if you select this option, all fields that appear on the Create screen will automatically be copied to the new issue(s). Note that the Create screen is specific to the issue type and project of the issue being created.
Copy all fields: if you select this option, all fields will be copied to the new issue(s). Note that you can still “override” the behavior for specific fields by adding them under the “Specific fields” section (see below).
To add a field: Select a field from the list of fields and click on Add.
To Remove an added field: Click on Remove to remove a field.
To Set a field value:
Copy value from current issue: Copies the field value(s) from the current issue.
Set field value to constant or Groovy template: You can set the field to a constant value optionally using Groovy Template markup to insert dynamic content. For example: To set the Description of the issue, you can specify This bug has been raised by <%=issue.get("reporter").getName()%> with <%=issue.get("priority").getName()%> priority. Act accordingly. in the value box.
Set field value to Groovy Expression: You can set the field to the result of a Groovy expression. For example, to set the Assignee to the Reporter of the issue, you can specify issue.get("reporter") in the value box.
See the Expected Value tab of the Groovy help editor or refer to the documentation to know more about the expected value for the selected field.
You can optionally copy all sub-tasks of the current issue to the newly created issue(s) by checking the “Copy sub-tasks to the new issue(s)” option.
You can run a Groovy script after each new issue is created.
Note that, during the execution of that script, the newIssue variable points to the newly created issue.
Adds a comment to the current issue.
Note that the newly created issue's key is available in the Groovy script context as the newIssueKey variable. For example, you can add a comment to the current issue: "Issue " + newIssueKey + "has been created.
Comment type: The text of the comment can either be a
Text or Groovy template: A fixed text that can include a Groovy template markup that can be used as the comment body. For example, The issue will be resolved on or before <%= issue.duedate%> by <%issue.assignee%>.
Groovy Expression: A Groovy expressionwhose return value (of type String) will be used as the comment body. For example, issue.get("description") will add the description of the issue to the issue as a comment.
Restrict to Group: Restricts the visibility of the comment to a specified group. When you select a valid group name in the Restrict to Group field, the comment will be visible only to the members of the specified group. For no restriction, leave the field blank.
Restrict to Project Role: Restricts the visibility of the comment to a selected project role. When you select a project role from the drop-down Restrict to Project Role field, the comment will be visible only to the members of the selected project role. For no restriction, leave the field blank.
Restrict to Internal (Jira Service Desk only): Restricts the visibility of the comment to the Service Desk Agents and Collaborators only. This requires the option Send "Issue Commented" notification to be selected.
Send "Issue Commented" notification: You can notify the users when a comment is added on the issue by selecting the option Send "Issue Commented" notification.
Multiple Issue Creation
By default, the Create/Clone issue post-function will create a single new issue, according to the settings above. If you want to create multiple issues at the same time, check the Create multiple issues option. You will then need to provide an iterator script that will control how many issues are created.
The iterator script is a custom Groovy script that must return an array or a collection of values. The post-function will iterate over this array or collection and create one new issue per value. If configured, a new comment will also be added to the current issue for each new issue created.
During the iteration, the current value is available to any Groovy scripts or Templates used in the rest of the configuration of the post-function above (field values, calculated project, post-creation script and comment) through the it global variable. It is also available for test in the Groovy editor and takes the first value of the iterator when tested against an issue.
Script returning an array of values
For example, if the iteration script returns the following array of values: ["jdoe","tblack"] then one issue will be created with the it variable containing "jdoe" and then another with the it variable containing "tblack". And if, in the configuration of the post-function, you are setting the "Assignee" field of the newly created issue to the following Constant or Groovy Template: $it then the first issue will be assigned to jdoe and the second to tblack.
1..5 will create 5 issues, with the it variable containing numbers from 1 to 5
Instead of being a simple string as in the example above, each value in the list can be an arbitrary Java object, which will be available through the it variable. For example, each value can be a Groovy Map, allowing multiple values to be passed to each iteration of the post-function. If the iteration script returns: [ [assignee:"jdoe", summary:"Issue for John Doe"] , [assignee:"tblack", summary:"Issue for Tim Black"] ] then you'll be able to use it.assignee as the Groovy Script value for the Assignee field, and it.summary as the Groovy Script value for the Summary field.
issue.get("Multi-user Picker field")
[ [assignee:"jdoe", summary:"Issue for John Doe"] , [assignee:"tblack", summary:"Issue for Tim Black"] ]
Note that all issues that are created by this post-function during the current transition are available through the transientVars.newIssues global variable.
Run as user: Any user specified in this field will be the creator of the new issue. Leave it blank for the current user to be the author.
By default, all errors (Java Exceptions) raised by this post-function, including those raised by custom Groovy scripts, will be logged in the JIRA log file but will not be reported to the user and will not prevent the transition from completing. However, when designing new workflows or troubleshooting them, it is more convenient to be notified immediately of any such error during the execution of the transition. For example on the production Jira instances you might want to show errors only for the post-function(s) being worked on, in order to avoid disrupting other workflows. To make errors raised by the current post-function prevent the transition from completing and show the error in the browser, select Make transition fail when an error occurs in this post-function.
If you want to show all the errors, either only to the admins or to all users, configure the option globally on the JMWE configuration page. For example, on development and staging Jira instances, you can activate error reporting for all JMWE post-functions, to display all the errors and it is recommended to do so, and on production Jira instances you might want to activate error reporting only to administrators so that they can be made aware of configuration errors.