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.
Hello, Automotive enthusiasts! Are you ready for October to begin 🙀? I wanted to share with you an Article I came across from Work/Life (The Atlassian blog) from Soumya Menon of Go2Group, a worldw...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event