Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Change Project on Create in Workflow?

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

1 comment

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 24, 2019

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

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?

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Apr 24, 2019

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.


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events