Limiting the Projects an Issue can be moved to during the Issue life cycle

[Nathaniel Hix]

I'm creating a new workflow, and would like to be able to enforce which projects an issue can be moved to.

For example, when code is released from engineering, it then should only be able to move to QA. QA can then assess the code, and either move it to Operations to deploy, or back to engineering. If it gets moved back, engineering can again only send it over to QA, not directly to Operations.

Is there any way to enforce a workflow like this?

[StevenA]

Hi Nathaniel,

YES, as your nature description. In your workflow, create 3 steps called: Engineering, QA and Operations. Then add 3 transitions, the first connect from Engineering->QA, the second one connect QA->Engineering and the final one connect QA->Operations. So there is no way to transition directly from Engineering to Operations.

Best Regards,

Steven

[Renjith Pillai]

Workflows in JIRA does not come with a functionality to move an issue to projects. Probably you need not worry about moving the issue across projects at all.

I see it like this:

The workflow includes different statuses like "With Development", "With QA", "With Operations" and each of those statuses being connected by transitions that are protected by conditions. These conditions should be using the project roles/groups for users from Dev/QA/Operations so that only they can execute the appropriate transition.

And in fact in enterprises being too strict with the workflow conditions only results in too much administrative overhead, you may also leave the workflow without any conditions as every change in JIRA gets recorded in the issue history and users do not usually make unnecessary changes to issues.