The attached screenshot shows the "Create" transition of any issue in JIRA workflows. Unfortunately there are two ways to reach that same transition from the JIRA UI:
1. An issue is being created using the "Create" button
2. An issue is being created using the More->Clone menu item of another issue

In my workflow, these two cases require significantly different handling. Specifically, my users like to use (2) instead of (1)

And in fact often they even prefer to clone an issue in the wrong project then move it to the right project instead of just using the "Create" button in the right project.

This known behavior was ok before one of our web hook integrations was built for two way sync of bugs, but it became catastrophic afterward. The classic error was to clone an issue to create a completely unrelated issue in a project that is not even tracked by this process. The result was a bunch of dangling bugs in the other application created "by mistake" because someone decided to "clone+move" instead of "create".

So I need two separate transitions, one for create and a different one for clone, in order to track the different set of actions that I need to take in one case or the other. Right now that can be done with undocumented code in Scriptrunner (so undocumented that I've never even got a straight answer from Jamie Echlin: https://answers.atlassian.com/questions/9863448/answers/38752668 ). Here's the code I'm using:

if(issue.key == null)

{ // If the issue is not a clone, we honor whatever issuetype that // was set at issue creation screen return }

else

{ // The issue is a clone. A few fields need to be purged here, because // purging them in normal post-functions would clear them even if they // had been explicitly set during the create screen of a new bug.  }

While this looks pretty simple, being completely undocumented means that every time the support team upgrades JIRA or the scriptrunner plugin, this might break.

The other, more annoying side effect is that once this logic is in play, any custom field that needs to be managed during this transition will need to be inside this same script, and I lose all the advantages of the JIRA UI managing post functions.

Specifically, in my bug workflow, when an issue is being cloned (but not when an issue is being created anew) I need to:

• Change the issuetype to "Bug" for clones to avoid unnecessary triggers
• Purge 4 custom fields

These custom fields cannot be purged on a "Create new" (as opposed to "Create clone") because they are present in the editor when an issue is created, and the user could decide to explicitly set them to something at creation time (same deal of the Issuetype "bug (public)").