So I did read those pages, but what is the business logic? If an issue is reported in ProjectA, but ProjectB in a different team will do the dev, but the issue will come back to Project A for testing, I think the issue should be linked to a new issue in ProjectB and then when dev is done, the ProjectA ticket will be moved to testing. Is that right?
My recommendation would be that you do not manage the issue in different projects then. Give the necessary permissions to every member involved in the issue lifecycle to one project and manage the life cycle at one project using workflow states - Development, testing, release etc. This way you only have one copy of the issue , there is no confusion which issue relates to which. Imagine the confusion if you have 500 issues all duplicated into multiple projects and linked together
When there are 2 separate work efforts, then I prefer the clone method with a separate workflow. And this is especially true if you do time tracking, do agile management, or have different code bases (perhaps a shared library). One issue to do the development effort development effort in project B and a second issue to do the acceptance testing or dependency updates of the change into project A.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs