Change Project on Create in Workflow?

[Larry Wilson]

On Creation of an Issue applying a specific Workflow, regardless of the Project the create is initiated from, I want the Issue to be created into the intended Project, if it exists.

I am hoping a regex for the (new) Issue Identifier of (sed standard) "^${PRODUCTMNEMONIC}(.*)-(.*)$" would identify the current Project. Where \1 is empty (Release Project) or one of PLN (Planning Project), CC (Change Control Project), or XXX (Deprecated Issues Project). And \2 would provide the Issue number.

I assume the number is "reserved" during the create but, if not, then I would just review the Project Identifier as "^${PRODUCTMNEMONIC}(.*)$"

Here is some background information to filter concerns through, ...

• There are 4 Projects created that apply to a single Program or Product.
• Each Project when created is assign a Product Mnemonic with format: %PRODUCTMNEMONIC%%FOCUS%
• The four primary Focuses using the DevOps Tool Kit as an example; PRODUCT = DOTK) are:
  • Baseline Release Projects: DOTK
  • Planning: DOTKPLN
  • Change Control: DOTKCC
  • Deprecated Issues: DOTKXXX
• ALL Projects apply the SAME Issue Type Scheme, Workflow Scheme, and Screen Schemes.
• ALL Projects sync their Version and Component declarations from the DOTKPLN project

[Nic Brough -Adaptavist-]

Moving an issue in Jira is one of the most complex things you can ask it to do.  It needs to check all the configuration, work out what might need to be changed and ask how to change it if necessary.

So, you'll need code to do this, and quite a lot of it.  A listener to catch the "create" can do the work, but it'll need to do a lot.

You've covered a lot by having the same issue types and workflows, but if any admin makes an unexpected change, any code you've written will corrupt the issue.

You'll need to duplicate all the versions and components as they get added

You'll need to warn your users to expect a lot of "holes" in numbers - when issues are moved, their sequence is left empty in the source project

[Larry Wilson]

Version and Component syncing is handled through an add-on, no worries. I only allow Version and Component creation under *PLN Project which then syncs to each of the other three Projects.

I (hoped) that I could change the Project after the Create Screen, basically intercepting the create, validating the Project against the Workflow.

Any Issue assigned to the Workflow using this Create validator shall ONLY have the Project changed if a Project with the derived Name exists, ...

That is not possible?

[Larry Wilson]

So, I gather there is no access to the raw creation before it occurs.

The validator is just pass or fail.

The post function is after the transition has occurred (ie, the issue has been created).

So, the original issue is always removing a KEY when it is deleted.

BUT, I guarantee, by design, that the Issue Type, Workflow, and Screen Schemes shall correlate.

I am not (currently) using a different Instance of JIRA, so that would not be an Issue.

By design, and enforcement, any conflict seen would simply cancel the "move" to a new Project and carry out the requested creation.

Isn't there some existing functionality that can be leveraged?

[Nic Brough -Adaptavist-]

No, the issue creation starts when the reporter hits the "create" button and at that point, it can only go through the process with the current structural data - project and issue type.

This is why you have to do it with a listener, and why it's complex and fragile.  It's not even a case of having identical config - if you don't do all the checks (and then ask or automatically fail), you can corrupt the issue (in the case where an admin has made the config non-identical because they had good intentions and did not know).

A better approach is to get the project right as part of the process of starting to create.