In the instruction for associating a workflow scheme with a project it says, "Click Associate to begin the migration process. Each issue needs to have a valid status, so you may need to assign statuses to a select number of issues after you switch workflow schemes."
If an issues exists in multiple projects does changing the status already assigned to it change the available status values for that issue across all projects in which it occurs? Or are the changes local to the workflow associated with a specific project?
For example,
I am attempting to associate a new workflow, "Auto-regression workflow Oct 2019" to an existing project. After clicking publish (I am assuming "publish" is the same as " Associate" in instruction snippet above) I am presented with this:
If I change the status of the Bug Issue from "In QA" to "In Progress" to be compatible with the "Auto-regression workflow Oct 2019" workflow, will this be a global change of the status effecting all instances of the Bug issue in all the projects it appears in, or will it just be local to the new workflow?
I have fallen foul of making what I thought was a local change but in fact it wasn't ( i.e., I change the name of a status) - I don't want to do that again!
Thanks in advance
Dave
Hi @David W ,the small number right beneath the issuetype ("Bug" in your screenshot) shows the number of issues of this type in your project.
If this value is "0" you can ignore the change. The status will be changed from "In QA" to "In Progress" for 0 issues, so you don't have to set anything.
Only if the number is > 0, you have to set a new status.
The status will be changed in all the projects which are using the changed workflow. This can be a single project but if the workflow is shared between several projects, the status will be changed in all these projects.
@Thomas Schlegel, thank you for the very speedy reply!
Can I clarify exactly what is going on.
When presented with options like the one in the screen shot two things are going on:
Cheers
Dave
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, that's true, "In QA" is not available anymore, because it's not part of the workflow anymore.
The number "0" means, that there are no issues of this type currently impacted by the workflow change.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Thomas Schlegel Thank you very much for you help - I have been brave enough to press the "Associate" button! No one has shouted, it looks like we are good.
Cheers
Dave
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @David W ,
1. If you edit the Existing Status name/category(e.g. In QA to "Some") that will reflect in whole server
2. If you remove one status and add another one or new status to the workflow and then publish it then this change will affect on all projects who are all sharing/using this workflow
3. If you copy/create new workflow and remove status from workflow, add new status to workflow --> associate it to particular project this change will affect only the project of associating current workflow
You can refer THIS atlassian documentation for more details
BR,
Leo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
A workflow belong to an issue type and it's associated by a project (via a worflow scheme).
In other words, if you change a workflow of a worflow scheme that belong to a project "A" it will be reflecting only in the project "A" even if the issuetype bug exist in project B or C.
Let me know if i'm not clear.
Hope this helps.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.