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.
Hi all Lets make this Friday fun really fun and post one (or more) of your best jokes! The joke can be about an Atlassian product, or just a really fun joke you want to share! I’m not the best j...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot