Description

Use case from Fabrizio Galletti:

When clicking on a particular workflow transition, I would like to:

1. Create a new ticket in a remote system
2. Copy values for some (all known) fields
3. Use the issue key of the issue in system A in a custom field in system B that links back to system A (basically just add it as a label in system B, I wrote a script that changes the base url of the label links to system A)
4. Use the resulting issue key of the new issue in system B in a custom field in system A (to link bi-directional)
5. Optionally: Don't show the status change in the activity log, since I like to transition to the same status

Steps

Lets walk through this. So, you will need a CLI post function.

1. Action will be a run action, product JIRA, with the appropriate server url and credentials. This allows us to run a number of different actions to do all the thing needed. These actions are added to the Data field, one action per line.
   
   1. createIssue will be the first action
   2. assume the project key on the target system is the same
2. Use Variable substitution to populate fields on the createIssue action from the original issue
   
   1. issue variables
   2. issue custom fields using setFieldValue actions for each of the custom fields
3. Use addLabels action to the the label to the original issue. Other situations might use a specific custom field for this value instead.
4. A second post function will be required to handle this, either using a CLI action for setFieldValue on the local system
5. This is just JIRA workflow - construct the transition to go back to the same state.

Example

First post function

Create the issue on the target system:

--action run --common "--project %project%" --server urlSystemB --user automation --password automation

-a createIssue --type %issueType% --summary "%summary%" --priority %priority%
-a setFieldValue --issue @issue@ --field custom1 --values "%custom1%"
-a setFieldValue --issue @issue@ --field custom2 --values "%custom2%"
-a addLabels --issue @issue@ --labels %issue_key%

Second post function

Update a custom field on the original issue to point to the newly created issue available from the %cli_replace_issue% substitution variable - the last CLI referenced issue from the previous post function.

--action setFieldValue --field remoteIssueKey --values %cli_replace_issue% --issue %original_key% --server %base_url% --user automation --password automation

Other suggestions

1. The URL of the created issue is easily available from the createIssue action message. The technique is shown in the older version of this page. This could be used to provide a link on the original issue to the new issue in a custom field or elsewhere instead of just using the issue key.